tags(5)

Universal Ctags

tags(5)

نام (NAME)

tags - قالب پرونده برچسب‌ها برای ویرایشگرها

توضیحات (DESCRIPTION)

محتوای بخش بعدی رونوشتی از پرونده FORMAT در کد منبع Exuberant Ctags در مخزن subversion آن در sourceforge.net است.

استثناهای ارائه‌شده در Universal Ctags به صورت درون‌خطی با نشانگر "EXCEPTION" توضیح داده شده‌اند. گزاره‌هایی که در Universal Ctags شفاف‌تر شده‌اند نیز به صورت درون‌خطی با نشانگر "COMMENT" شرح داده شده‌اند.

----

طرح پیشنهادی برای قالب گسترش‌یافته پرونده برچسب‌های Vi

Version: 0.06 DRAFT
Date: 1998 Feb 8
Author: Bram Moolenaar <Bram at vim.org> and Darren Hiebert <dhiebert at users.sourceforge.net>

مقدمه (Introduction)

قالب پرونده برای پرونده "tags"، همان‌طور که توسط Vi و بسیاری از مشتقات آن استفاده می‌شود، قابلیت‌های محدودی دارد.

این قابلیت‌های افزوده مورد نیاز است:

1.: برچسب‌های ایستا یا محلی (Static or local tags). حوزه این برچسب‌ها پرونده‌ای است که در آن تعریف شده‌اند. یک برچسب یکسان می‌تواند در چندین پرونده ظاهر شود، بدون اینکه واقعاً یک برچسب تکراری باشد.
2.: برچسب‌های تکراری (Duplicate tags). امکان وقوع یک برچسب یکسان بیش از یک بار. آن‌ها می‌توانند در پرونده‌ای دیگر قرار داشته باشند و/یا دستور متفاوتی داشته باشند.
3.: پشتیبانی از ++C. یک برچسب نه تنها با نام خود، بلکه با زمینه (نام کلاس) نیز مشخص می‌شود.
4.: گسترش‌پذیری در آینده (Future extension). هنگامی که قابلیت‌های بیشتری مورد نیاز باشد، باید بتوان آن را بعداً اضافه کرد، بدون اینکه برنامه‌هایی که از آن پشتیبانی نمی‌کنند دچار شکست شوند.

از طرح پیشنهادی تا استاندارد (From proposal to standard)

برای تبدیل این طرح پیشنهادی به یک استاندارد برای پرونده‌های برچسب‌ها، باید توسط اکثر افرادی که روی نسخه‌های Vi، ctags و غیره کار می‌کنند پشتیبانی شود. در حال حاضر این استاندارد توسط افراد زیر پشتیبانی می‌شود:

Darren Hiebert <dhiebert at users.sourceforge.net>: Exuberant Ctags
Bram Moolenaar <Bram at vim.org>: Vim (Vi IMproved)

از پروژه‌های زیر خواسته شده یا خواهد شد که از این استاندارد پشتیبانی کنند:

Nvi: Keith Bostic <bostic at bsdi.com>
Vile: Tom E. Dickey <dickey at clark.net>
NEdit: Mark Edel <edel at ltx.com>
CRiSP: Paul Fox <fox at crisp.demon.co.uk>
Lemmy: James Iuliano <jai at accessone.com>
Zeus: Jussi Jumppanen <jussij at ca.com.au>
Elvis: Steve Kirkendall <kirkenda at cs.pdx.edu>
FTE: Marko Macek <Marko.Macek at snet.fri.uni-lj.si>

سازگاری عقروعلی (Backwards compatibility)

یک پرونده برچسب‌ها که با قالب جدید تولید می‌شود، همچنان باید برای Vi قابل استفاده باشد. این امر توزیع پرونده‌های برچسب‌هایی را ممکن می‌سازد که توسط تمام نسخه‌ها و مشتقات Vi قابل استفاده باشند.

این امر قالب را به آنچه Vi می‌تواند مدیریت کند محدود می‌سازد. قالب به شرح زیر است:

1.: پرونده برچسب‌ها فهرستی از خطوط است، هر خط در قالب:

{tagname}<Tab>{tagfile}<Tab>{tagaddress}

{tagname}: هر شناسه‌ای، بدون نویسه فاصله..
EXCEPTION: Universal Ctags این مورد از پیشنهاد را نقض می‌کند؛ tagname می‌تواند شامل نویسه‌های فاصله (spaces) باشد. با این حال، نویسه تب (tab) مجاز نیست.
<Tab>: دقیقاً یک نویسه TAB (اگرچه بسیاری از نسخه‌های Vi می‌توانند هر مقداری از نویسه‌های فاصله‌ای را مدیریت کنند).
{tagfile}: نام پرونده‌ای که {tagname} در آن تعریف شده است، به صورت نسبی نسبت به دایرکتوری فعلی (یا مکان پرونده برچسب‌ها؟).
{tagaddress}: هر دستور Ex. هنگام اجرا، به گونه‌ای رفتار می‌کند که گویی 'magic' تنظیم نشده است.

2.: پرونده برچسب‌ها بر اساس {tagname} مرتب می‌شود. این امر امکان جستجوی دودویی در پرونده را فراهم می‌کند.
3.: برچسب‌های تکراری مجاز هستند، اما اینکه کدام‌یک در عمل استفاده شود غیرقابل پیش‌بینی است (به دلیل جستجوی دودویی).

بهترین راه برای افزودن متن اضافی به خط به منظور قابلیت‌های جدید، بدون ایجاد ناسازگاری برای Vi، قرار دادن یک کامنت در {tagaddress} است. این کار آزادی استفاده از هر متنی را می‌دهد و باید در هر پیاده‌سازی سنتی Vi کار کند.

به عنوان مثال، زمانی که پرونده برچسب‌های قدیمی شامل موارد زیر است:

main    main.c  /^main(argc, argv)$/
DEBUG   defines.c       89

خطوط جدید می‌توانند چنین باشند:

main    main.c  /^main(argc, argv)$/;"any additional text
DEBUG   defines.c       89;"any additional text

توجه داشته باشید که نویسه ';' برای قرار دادن مکان‌نما در خط درست الزامی است و سپس نویسه '"' به عنوان آغاز یک کامنت شناسایی می‌شود.

برای نسخه‌های Vi سازگار با Posix این روش کار نخواهد کرد، زیرا فقط یک شماره خط یا یک دستور جستجو شناسایی می‌شود. امید است Posix اصلاح شود. Nvi از این مسئله متأثر است.

امنیت (Security)

نرم‌افزار Vi اجازه استفاده از هر دستور Ex را در پرونده برچسب‌ها می‌دهد. این امر پتانسیل یک رخنه امنیتی اسب تروجان را به همراه دارد.

طرح پیشنهادی این است که فقط دستورات Ex مجاز باشند که مکان‌نما را در یک پرونده منفرد قرار می‌دهند. دستورات دیگر، مانند ویرایش پرونده‌ای دیگر، خروج از ویرایشگر، تغییر یک پرونده یا نوشتن در یک پرونده، مجاز نیستند. بنابراین منطقی است که این دستور را یک tagaddress بنامیم.

به طور مشخص، این دو دستور Ex مجاز هستند:

•: یک شماره خط ده‌دهی:

•: یک دستور جستجو. این یک الگوی عبارت باقاعده است، همان‌طور که توسط Vi استفاده می‌شود، محصور در // یا ??:

/^int c;$/
?main()?

دو ترکیب امکان‌پذیر است:

•: الحاق موارد بالا، با قرار گرفتن ';' در بین آن‌ها. معنای آن این است که نخستین شماره خط یا دستور جستجو استفاده می‌شود، مکان‌نما در آن خط قرار می‌گیرد و سپس دومین دستور جستجو استفاده می‌شود (شماره خط مفید نخواهد بود). این کار را می‌توان چندین بار انجام داد. این روش زمانی مفید است که اطلاعات موجود در یک خط منحصربه‌فرد نبوده و جستجو باید از یک خط مشخص آغاز شود.

/struct xyz {/;/int count;/
389;/struct foo/;/char *s;/

•: می‌توان یک کامنت پایانی افزود که با ';"' (دو نویسه: نقطه-ویرگول و گیومه دوگانه) آغاز می‌شود. این مورد در زیر استفاده شده است.

89;" foo bar

این ساختار ممکن است در آینده گسترش یابد. آنچه در حال حاضر وجود ندارد، راهی برای قرار دادن مکان‌نما در یک ستون خاص است.

اهداف (Goals)

اکنون کاربرد متن کامنت باید تعریف شود. اهداف زیر مد نظر است:

1.: کوتاه نگه داشتن متن، زیرا:

طول خطی که Vi می‌تواند پردازش کند به 512 نویسه محدود است.
پرونده‌های برچسب‌ها می‌توانند شامل هزاران برچسب باشند. پرونده‌های برچسب‌های چندین مگابایتی دیده شده است.
متن بیشتر جستجو را کندتر می‌کند.

2.: خوانا نگه داشتن متن، زیرا:

اغلب بررسی خروجی یک برنامه ctags جدید ضروری است.
امکان ویرایش پرونده با دست وجود داشته باشد.
نوشتن برنامه‌ای برای تولید یا تجزیه پرونده آسان‌تر شود.

3.: عدم استفاده از نویسه‌های خاص، زیرا:

•: باید بتوان با پرونده برچسب‌ها مانند هر پرونده متنی معمولی رفتار کرد.

طرح پیشنهادی (Proposal)

استفاده از یک کامنت پس از فیلد {tagaddress}. قالب به صورت زیر خواهد بود:

{tagname}<Tab>{tagfile}<Tab>{tagaddress}[;"<Tab>{tagfield}..]

{tagname}: هر شناسه‌ای، بدون نویسه فاصله..
EXCEPTION: Universal Ctags این مورد از پیشنهاد را نقض می‌کند؛ نام ممکن است شامل نویسه‌های فاصله باشد. با این حال، نویسه تب مجاز نیست. تبدیل برای برخی نویسه‌ها از جمله <Tab> در "value"، که در انتهای این بخش شرح داده شده است، اعمال می‌شود.
<Tab>: دقیقاً یک نویسه TAB (اگرچه بسیاری از نسخه‌های Vi می‌توانند هر مقداری از نویسه‌های فاصله‌ای را مدیریت کنند).
{tagfile}: نام پرونده‌ای که {tagname} در آن تعریف شده است، به صورت نسبی نسبت به دایرکتوری فعلی (یا مکان پرونده برچسب‌ها؟).
{tagaddress}: هر دستور Ex. هنگام اجرا، به گونه‌ای رفتار می‌کند که گویی 'magic' تنظیم نشده است. ممکن است به یک شماره خط یا یک الگوی جستجو محدود شود (Posix).
COMMENT: بخش {tagaddress} می‌تواند شامل نویسه‌های تب باشد. برای چگونگی استخراج و تجزیه برنامه‌نویسی {tagaddress} (که در آنجا "pattern field" نامیده می‌شود) به ctags-client-tools(7) مراجعه کنید.

به صورت اختیاری:

;": نقطه-ویرگول + گیومه دوگانه: به tagaddress به گونه‌ای پایان می‌دهد که برای Vi شبیه آغاز یک کامنت به نظر برسد.
{tagfield}: به بخش زیر مراجعه کنید.

یک tagfield دارای یک نام، یک دونقطه و یک مقدار است: "name:value".

نام فقط از نویسه‌های الفبایی تشکیل می‌شود. حروف بزرگ و کوچک مجاز هستند. استفاده از حروف کوچک توصیه می‌شود. حروف بزرگ و کوچک متمایز هستند ("kind:" و "Kind: دو tagfield متفاوت هستند).
EXCEPTION: Universal Ctags به کاربران اجازه می‌دهد در نام به جز حرف آغازین از نویسه‌های عددی نیز استفاده کنند.
مقدار می‌تواند خالی باشد. نمی‌تواند شامل یک <Tab> باشد.

هنگامی که یک مقدار شامل \t باشد، نشان‌دهنده یک <Tab> است.
هنگامی که یک مقدار شامل \r باشد، نشان‌دهنده یک <CR> است.
هنگامی که یک مقدار شامل \n باشد، نشان‌دهنده یک <NL> است.
هنگامی که یک مقدار شامل \\ باشد، نشان‌دهنده یک نویسه منفرد \ است.

سایر کاربردهای نویسه بک‌اسلش برای گسترش‌های آینده محفوظ است. هشدار: هنگامی که مقدار tagfield حاوی یک نام پرونده MS-DOS باشد، بک‌اسلش‌ها باید دوبرابر شوند!

EXCEPTION: Universal Ctags قواعد تبدیل بیشتری را معرفی می‌کند.

هنگامی که یک مقدار شامل \a باشد، نشان‌دهنده یک <BEL> (0x07) است.
هنگامی که یک مقدار شامل \b باشد، نشان‌دهنده یک <BS> (0x08) است.
هنگامی که یک مقدار شامل \v باشد، نشان‌دهنده یک <VT> (0x0b) است.
هنگامی که یک مقدار شامل \f باشد، نشان‌دهنده یک <FF> (0x0c) است.
نویسه‌ها در محدوده 0x01 تا 0x1F شامل، و 0x7F در صورتی که در قواعد "value" بالا مدیریت نشده باشند، به عدد هگزادسیمال با پیشوند \x تبدیل می‌شوند.

EXCEPTION: Universal Ctags تمام این توالی‌های گریز را در {tagname} و {tagfile} نیز مجاز می‌داند. با این حال، درباره {tagfile}، باید شرطی برقرار باشد. برای آگاهی از این شرط به "Exceptions in Universal Ctags" مراجعه کنید.

•: فاصله ابتدایی (0x20) و ! (0x21) در {tagname} در صورتی که برچسب یک شبه‌برچسب نباشد، به عدد هگزادسیمال با پیشوند \x (\x20 و \x21) تبدیل می‌شوند. همان‌طور که بعداً شرح داده می‌شود، یک شبه‌برچسب با ! شروع می‌شود. این قواعد برای تمایز شبه‌برچسب‌ها و برچسب‌های غیر شبه‌برچسب (برچسب‌های معمولی) هنگام مرتب‌سازی خطوط در یک پرونده برچسب‌ها هستند.

نام‌های پیشنهادی برای tagfield:

FIELD-NAME	DESCRIPTION
arity	تعداد آرگومان‌ها برای یک برچسب تابع.
class	نام کلاسی که این برچسب عضو یا متدی از آن است.
enum	نام نوع شمارشی که این برچسب یکی از عناصر آن است.
file	برچسب ایستا (محلی)، با حوزه پرونده مشخص‌شده. هنگامی که مقدار خالی باشد، از {tagfile} استفاده می‌شود.
function	تابعی که این برچسب در آن تعریف شده است. برای متغیرهای محلی (و توابع محلی) مفید است. هنگامی که توابع تودرتو هستند (مانند پاسکال)، نام توابع با '/' به یکدیگر متصل می‌شوند، به طوری که شبیه یک مسیر به نظر می‌رسد.
kind	نوع برچسب. مقدار به زبان بستگی دارد. برای C و ++C این نوع‌ها توصیه می‌شوند: 0.0 c نام کلاس (class name) d تعریف ماکرو (از #define XXX) e عنصر شمارشی (enumerator) f نام تابع یا متد (function or method name) F نام پرونده (file name) g نام نوع شمارشی (enumeration name) m عضو (از داده‌های ساختار یا کلاس) p پیش‌نمونه تابع (function prototype) s نام ساختار (structure name) t تعریف نوع (typedef) u نام اجتماع (union name) v متغیر (variable) 168u هنگامی که این فیلد حذف شود، نوع برچسب تعریف‌نشده است.
struct	نام ساختاری که این برچسب عضوی از آن است.
union	نام اجتماعی که این برچسب عضوی از آن است.

توجه داشته باشید که این موارد بیشتر برای C و ++C هستند. هنگامی که برنامه‌های برچسب‌گذاری برای زبان‌های دیگر نوشته می‌شوند، این فهرست باید گسترش یابد تا نام‌های فیلد استفاده‌شده را شامل شود. این امر به کاربران کمک می‌کند تا از برنامه برچسب‌گذاری مورد استفاده مستقل باشند.

مثال‌ها:

asdf    sub.cc  /^asdf()$/;"    new_field:some\svalue   file:
foo_t   sub.h   /^typedef foo_t$/;"     kind:t
func3   sub.p   /^func3()$/;"   function:/func1/func2   file:
getflag sub.c   /^getflag(arg)$/;"      kind:f  file:
inc     sub.cc  /^inc()$/;"     file: class:PipeBuf

نام فیلد "kind:" را می‌توان حذف کرد. این کار برای کاهش حجم پرونده برچسب‌ها تا حدود ۱۵٪ است. برنامه‌ای که پرونده برچسب‌ها را می‌خواند می‌تواند فیلد "kind:" را از روی نبود ':' تشخیص دهد. مثال‌ها:

foo_t   sub.h   /^typedef foo_t$/;"     t
getflag sub.c   /^getflag(arg)$/;"      f       file:

ملاحظات تکمیلی:

•: هنگامی که یک tagfield دوبار در یک خط برچسب ظاهر شود، فقط مورد آخر استفاده می‌شود.

نکته‌ای درباره جداکننده‌های خط:

نرم‌افزار Vi به طور سنتی بر روی سیستم‌های یونیکس اجرا می‌شود، جایی که جداکننده خط یک نویسه خط‌جدید منفرد <NL> است. در MS-DOS و سیستم‌های سازگار، <CR><NL> جداکننده استاندارد خط است. برای افزایش سازگاری و انتقال‌پذیری، این جداکننده خط نیز پشتیبانی می‌شود.

در مکینتاش از یک <CR> منفرد به عنوان جداکننده خط استفاده می‌شود. پشتیبانی از این مورد در سیستم‌های یونیکس ایجاد مشکل می‌کند، زیرا اکثر پیاده‌سازی‌های fgets() نویسه <CR> را به عنوان جداکننده خط در نظر نمی‌گیرند. بنابراین پشتیبانی از <CR> به عنوان جداکننده خط محدود به مکینتاش است.

خلاصه:

جداکننده خط	تولیدشده در	پذیرفته‌شده در
<LF>	یونیکس	یونیکس، MS-DOS، مکینتاش
<CR>	مکینتاش	مکینتاش
<CR><LF>	MS-DOS	یونیکس، MS-DOS، مکینتاش

نویسه‌های <CR> و <LF> را نمی‌توان در داخل یک خط برچسب استفاده کرد. این موضوع در جای دیگری ذکر نشده است (زیرا بدیهی است).

نکته‌ای درباره نویسه‌های فاصله (white space):

نرم‌افزار Vi اجازه می‌داد از هر نویسه فاصله‌ای برای جداسازی tagname از tagfile و نام پرونده از tagaddress استفاده شود. این قابلیت باید برای حفظ سازگاری عقروعلی مجاز می‌بود. با این حال، تمامی برنامه‌های شناخته‌شده‌ای که برچسب‌ها را تولید می‌کنند از یک <Tab> منفرد برای جداسازی فیلدها استفاده می‌کنند.

استفاده از نام‌های پرونده حاوی نویسه‌های فاصله در فیلد tagfile با مشکل همراه است. برای رفع این مشکل، می‌توان از همان نویسه‌های خاص استفاده‌شده در فیلدهای جدید استفاده کرد، به عنوان مثال \s. اما متأسفانه در MS-DOS از نویسه بک‌اسلش برای جداسازی نام پرونده‌ها استفاده می‌شود. نام پرونده c:\vim\sap حاوی \s است، اما این یک <Space> نیست. تعداد بک‌اسلش‌ها را می‌توان دوبرابر کرد، اما این کار نویسه‌های زیادی می‌افزاید و تجزیه پرونده برچسب‌ها را کندتر و پیچیده‌تر می‌کند.

برای جلوگیری از این مشکلات، ما فقط اجازه می‌دهیم یک <Tab> فیلدها را جدا کند و از نام پرونده یا tagname حاوی نویسه <Tab> پشتیبانی نمی‌کنیم. این بدان معناست که ما ۱۰۰٪ با Vi سازگار نیستیم. با این حال، هیچ برنامه شناخته‌شده‌ای برای برچسب‌ها وجود ندارد که از چیزی غیر از <Tab> برای جداسازی فیلدها استفاده کند. فقط زمانی که کاربر خود پرونده برچسب‌ها را تایپ کرده باشد، یا برنامه اختصاصی خود را برای تولید پرونده برچسب‌ها ساخته باشد، ممکن است با مشکل روبرو شویم. برای حل این مشکل، پرونده برچسب‌ها باید فیلتر شود تا نویسه‌های فاصله دلخواه با یک <Tab> منفرد جایگزین گردند. از این دستور Vi می‌توان استفاده کرد:

:%s/^\([^ ^I]*\)[ ^I]*\([^ ^I]*\)[ ^I]*/\1^I\2^I/

(نویسه ^I را با یک <Tab> واقعی جایگزین کنید).

COMMENT: Universal Ctags هنگام اجرا روی MS Windows جداکننده \ را به طور پیش‌فرض به / تبدیل می‌کند و در صورت برقراری یک شرط، توالی‌های گریز را حتی در {tagfile} نیز مجاز می‌داند. برای آگاهی از این شرط به "Exceptions in Universal Ctags" مراجعه کنید.

اطلاعات پرونده برچسب‌ها (TAG FILE INFORMATION):

می‌توان از خطوط شبه‌برچسب برای کدگذاری اطلاعات مربوط به جزئیات محتوای پرونده برچسب‌ها (مثلاً: آیا برچسب‌ها مرتب شده‌اند؟ آیا فیلدهای اختیاری tagfield حضور دارند؟) و درباره برنامه استفاده‌شده برای تولید پرونده برچسب‌ها بهره برد. این اطلاعات می‌تواند هم برای بهینه‌سازی استفاده از پرونده برچسب‌ها (مثلاً فعال/غیرفعال کردن جستجوی دودویی) و هم برای ارائه اطلاعات عمومی (کدام نسخه از تولیدکننده استفاده شده است) به کار رود.

نام‌های برچسب‌های استفاده‌شده در این خطوط ممکن است به گونه‌ای مناسب انتخاب شوند تا اطمینان حاصل گردد که پس از مرتب‌سازی، همیشه در نزدیکی خطوط نخستین پرونده برچسب‌ها قرار می‌گیرند. استفاده از "!_TAG_" توصیه می‌شود. توجه داشته باشید که یک برچسب نادر مانند "!" می‌تواند در مرتب‌سازی پیش از این خطوط قرار گیرد. برنامه‌ای که پرونده برچسب‌ها را می‌خواند باید به اندازه کافی هوشمند باشد تا از روی این برچسب‌ها بگذرد.

خطوط شرح‌داده‌شده در زیر برای انتقال مجموعه‌ای منتخب از اطلاعات انتخاب شده‌اند.

خطوط برچسب ارائه‌دهنده اطلاعات درباره محتوای پرونده برچسب‌ها:

!_TAG_FILE_FORMAT   {version-number}        /optional comment/
!_TAG_FILE_SORTED   {0|1}                   /0=unsorted, 1=sorted/

مقدار {version-number} استفاده‌شده در خط قالب پرونده برچسب‌ها، مقدار "1" را برای پرونده‌های برچسب‌های سازگار با قالب اصلی UNIX vi/ctags رزرو می‌کند و مقدار "2" را برای پرونده‌های برچسب‌های سازگار با این طرح پیشنهادی در نظر می‌گیرد. این مقدار می‌تواند برای تشخیص حضور ویژگی‌های گسترش‌یافته شرح‌داده‌شده در این طرح پیشنهادی استفاده شود.

خطوط برچسب ارائه‌دهنده اطلاعات درباره برنامه مورد استفاده برای تولید پرونده برچسب‌ها، که صرفاً برای اهداف مستندسازی ارائه شده‌اند:

!_TAG_PROGRAM_AUTHOR        {author-name}   /{email-address}/
!_TAG_PROGRAM_NAME  {program-name}  /optional comment/
!_TAG_PROGRAM_URL   {URL}   /optional comment/
!_TAG_PROGRAM_VERSION       {version-id}    /optional comment/

EXCEPTION: Universal Ctags انواع بیشتری از شبه‌برچسب‌ها را معرفی می‌کند. برای اطلاعات بیشتر درباره آن‌ها به ctags-client-tools(7) مراجعه کنید.

COMMENT: اگرچه شبه‌برچسب‌ها از نظر معنایی با برچسب‌های معمولی متفاوت هستند، اما از همان قالب استفاده می‌کنند که به شرح زیر است:

{tagname}<Tab>{tagfile}<Tab>{tagaddress}

و توالی‌های گریز و نویسه‌های غیرمجاز توضیح‌داده‌شده در بخش "Proposal" بر شبه‌برچسب‌ها نیز اعمال می‌شوند.

----

استثناها در Universal Ctags (Exceptions in Universal Ctags)

Universal Ctags از این طرح پیشنهادی با اعمال برخی استثناها پشتیبانی می‌کند.

استثناها (Exceptions)

1.: بخش {tagname} در پرونده برچسب‌های تولیدشده توسط Universal Ctags ممکن است شامل فاصله‌ها و چندین توالی گریز باشد. تجزیه‌کننده‌ها برای اسنادی مانند Tex و reStructuredText یا زبان‌های منعطفی مانند JavaScript به این استثناها نیاز دارند. برای جزئیات بیشتر درباره تبدیل، به {tagname} در بخش Proposal مراجعه کنید.
2.: بخش {tagfile} در پرونده برچسب‌های تولیدشده توسط Universal Ctags ممکن است شامل فاصله‌ها و چندین توالی گریز باشد در صورتی که نویسه‌های \ به عنوان جداکننده نام پرونده استفاده نشده باشند. سیستم‌های شبه‌یونیکس از / برای این منظور استفاده می‌کنند. در MS Windows، برنامه Universal Ctags نویسه‌های \ در نام پرونده‌ها را به طور پیش‌فرض به / تبدیل می‌کند. بنابراین معمولاً این شرط برآورده می‌شود. Universal Ctags چندین شبه‌برچسب منتشر می‌کند که نشان می‌دهند آیا شرط مربوطه برآورده شده است یا خیر. درباره این شبه‌برچسب‌ها به ctags-client-tools(7) مراجعه کنید.
3.: بخش "name" در {tagfield} در برچسب تولیدشده توسط Universal Ctags ممکن است حاوی نویسه‌های عددی باشد، اما نخستین نویسه "name" باید یک حرف الفبایی باشد.

خروجی سازگار و ضعف‌ها (Compatible output and weakness)

رفتار پیش‌فرض (گزینه --output-format=u-ctags) شامل این استثناها است. از سوی دیگر، با گزینه --output-format=e-ctags، ابزار ctags هیچ استثنایی ندارد؛ دستور Universal Ctags ممکن است از همان قالب پرونده مشابه Exuberant Ctags استفاده کند. با این حال، --output-format=e-ctags هر مدخل برچسبی را که نام آن شامل نویسه فاصله یا تب باشد دور می‌اندازد. شبه‌برچسب TAG_OUTPUT_MODE مشخص می‌کند که کدام قالب هنگام تولید پرونده برچسب‌ها توسط ctags به کار رفته است.

همچنین ببینید (SEE ALSO)

ctags(1), ctags-client-tools(7), ctags-incompatibilities(7), readtags(1)