ctags-client-tools(7)

📦
version 6.2.1 · 3 versions
, in ubuntu resolute, ubuntu stonking

💖 ctags-client-tools ✨

hiii bestie 🫶 welcome to ctags-client-tools(7), a page from the Universal Ctags manual. it's literally the group chat for anyone out here building a client tool on top of ctags. grab a boba, we're doing this 💅

🌈 SYNOPSIS 🌈

ctags [options] [file(s)]
etags [options] [file(s)]

🦋 DESCRIPTION 🦋

okay so, a client tool is any tool that runs the ctags command and/or reads a tags file that the ctags command generated. simple as that, no cap.

this man page is basically a lil care package 📦 of hints for the people who develop those client tools. you. you're the people. 💖

✨ PSEUDO-TAGS ✨

Pseudo-tags live inside a tag file and they're the receipts 🧾 for how ctags generated that file: is the tags file sorted or not, which version of the tags file format got used, who's the tags generator, etc etc. the whole lore.

the opposite of a pseudo-tag is a regular-tag. a regular-tag is about a language object in an input file. a pseudo-tag is about the tags file itself. client tools can totally use pseudo-tags as a reference when they're processing regular-tags — it's giving cheat sheet 📋.

a pseudo-tag is stored in a tags file in the same format as regular-tags, exactly like tags(5) describes, EXCEPT that pseudo-tag names are prefixed with "!_". for the general info about pseudo-tags, go peek at "TAG FILE INFORMATION" in tags(5).

here's an example of a pseudo tag:

!_TAG_PROGRAM_NAME      Universal Ctags /Derived from Exuberant Ctags/

the value, "Universal Ctags", is associated with the pseudo tag TAG_PROGRAM_NAME, and it's used in the field for input file. the description, "Derived from Exuberant Ctags", is used in the field for pattern. iconic behavior honestly.

Universal Ctags extends the naming scheme of the classical pseudo-tags that were available in Exuberant Ctags, so it can emit language-specific info as pseudo tags:

!_{pseudo-tag-name}!{language-name}     {associated-value}      /{description}/

the language-name gets appended to the pseudo-tag name with a separator, "!". yes, the exclamation mark. it's dramatic, we love it 💅

an example of a pseudo tag with a language suffix:

!_TAG_KIND_DESCRIPTION!C        f,function      /function definitions/

this pseudo-tag is basically saying "the function kind of C language is enabled when generating this tags file." fr fr.

--pseudo-tags is the option for enabling/disabling individual pseudo-tags. when you're enabling/disabling a pseudo tag with that option, you specify the tag name only — like TAG_KIND_DESCRIPTION — without the prefix ("!_") or the suffix ("!C"). don't add them, bestie, the option doesn't want them.

💅 Options for Pseudo-tags 💅

  • --extras=+p (or --extras=+{pseudo}) — forces writing pseudo-tags.

ctags emits pseudo-tags by default when it's writing tags to a regular file (e.g. tags). BUT when you specify -o - or -f - for writing tags to standard output, ctags doesn't emit pseudo-tags. --extras=+p or --extras=+{pseudo} will force those pseudo-tags to be written anyway. 😤

  • --list-pseudo-tags — lists available types of pseudo-tags and shows whether they're enabled or disabled.

run ctags with --list-pseudo-tags and it lists the available pseudo-tags for you. some of the pseudo-tags newly introduced in the Universal Ctags project are disabled by default. use --pseudo-tags=... to enable them. go wake them up 🫶

  • --pseudo-tags=[+|-]names|* — specifies a list of pseudo-tag types to include in the output.

the parameters are a set of pseudo tag names. valid pseudo tag names can be listed with --list-pseudo-tags. surround each name in the set with braces, like "{TAG_PROGRAM_AUTHOR}". you don't have to include the "!_" pseudo tag prefix when specifying a name in the option argument for the --pseudo-tags= option.

pseudo-tags don't have a notation using one-letter flags. periodt.

if a name is preceded by either the '+' or '-' characters, that tag's effect has been added or removed. otherwise the names replace any current settings. all entries are included if '*' is given. all entries are removed if nothing ('') is given.

  • --fields=+E (or --fields=+{extras}) — attaches the "extras:pseudo" field to pseudo-tags.

here's an example of pseudo tags with that field:

!_TAG_PROGRAM_NAME      Universal Ctags /Derived from Exuberant Ctags/  extras:pseudo

if the name of a regular tag in a tag file starts with "!_", a client tool literally cannot tell whether that tag is a regular-tag or a pseudo-tag 😭. the fields attached with this option help your tool distinguish them. you're welcome.

🔍 List of notable pseudo-tags 🔍

running ctags with the --list-pseudo-tags option lists the available types of pseudo-tags along with short descriptions. this subsection shows hints for using the notable ones. let's get into it ✨

🌸 TAG_EXTRA_DESCRIPTION (new in Universal Ctags) 🌸

indicates the names and descriptions of enabled extras:

!_TAG_EXTRA_DESCRIPTION       {extra-name}    /description/
!_TAG_EXTRA_DESCRIPTION!{language-name}       {extra-name}    /description/

if your tool relies on some extra tags (extras), refer to the pseudo-tags of this type. a tool can reject a tags file that doesn't include the expected extras, and raise an error in an early stage of processing. early detection, slay 💅

an example of the pseudo-tags:

$ ctags --extras=+p --pseudo-tags='{TAG_EXTRA_DESCRIPTION}' -o - input.c
!_TAG_EXTRA_DESCRIPTION       anonymous       /Include tags for non-named objects like lambda/
!_TAG_EXTRA_DESCRIPTION       fileScope       /Include tags of file scope/
!_TAG_EXTRA_DESCRIPTION       pseudo  /Include pseudo tags/
!_TAG_EXTRA_DESCRIPTION       subparser       /Include tags generated by subparsers/
...

a client tool can know that "{anonymous}", "{fileScope}", "{pseudo}", and "{subparser}" extras are enabled, just from the output. no cap 👑

Universal Ctags version 6.0 will turn on this pseudo tag by default.

🌸 TAG_FIELD_DESCRIPTION (new in Universal Ctags) 🌸

indicates the names and descriptions of enabled fields:

!_TAG_FIELD_DESCRIPTION       {field-name}    /description/
!_TAG_FIELD_DESCRIPTION!{language-name}       {field-name}    /description/

if your tool relies on some fields, refer to the pseudo-tags of this type. a tool can reject a tags file that doesn't include the expected fields, and raise an error in an early stage of processing.

an example of the pseudo-tags:

$ ctags --fields-C=+'{macrodef}' --extras=+p --pseudo-tags='{TAG_FIELD_DESCRIPTION}' -o - input.c
!_TAG_FIELD_DESCRIPTION       file    /File-restricted scoping/
!_TAG_FIELD_DESCRIPTION       input   /input file/
!_TAG_FIELD_DESCRIPTION       name    /tag name/
!_TAG_FIELD_DESCRIPTION       pattern /pattern/
!_TAG_FIELD_DESCRIPTION       typeref /Type and name of a variable or typedef/
!_TAG_FIELD_DESCRIPTION!C     macrodef        /macro definition/
...

a client tool can know that "{file}", "{input}", "{name}", "{pattern}", and "{typeref}" fields are enabled from the output. these fields are common across languages. and on top of the common fields, the tool can know that the "{macrodef}" field of C language is also enabled. look at you, knowing things 🥹

Universal Ctags version 6.0 will turn on this pseudo tag by default.

🌸 TAG_FILE_ENCODING (new in Universal Ctags) 🌸

TBW 🙈 (the author really left this one on read)

🌸 TAG_FILE_FORMAT 🌸

see also tags(5).

🌸 TAG_FILE_SORTED 🌸

see also tags(5).

🌸 TAG_KIND_DESCRIPTION (new in Universal Ctags) 🌸

indicates the names and descriptions of enabled kinds:

!_TAG_KIND_DESCRIPTION!{language-name}        {kind-letter},{kind-name}       /description/

if your tool relies on some kinds, refer to the pseudo-tags of this type. a tool can reject the tags file that doesn't include the expected kinds, and raise an error in an early stage of processing.

kinds are language specific, so a language name is always appended to the tag name as a suffix. no exceptions, bestie.

an example of the pseudo-tags:

$ ctags --extras=+p --kinds-C=vfm --pseudo-tags='{TAG_KIND_DESCRIPTION}' -o - input.c
!_TAG_KIND_DESCRIPTION!C      f,function      /function definitions/
!_TAG_KIND_DESCRIPTION!C      m,member        /struct, and union members/
!_TAG_KIND_DESCRIPTION!C      v,variable      /variable definitions/
...

a client tool can know that "{function}", "{member}", and "{variable}" kinds of C language are enabled from the output. ate 💅

Universal Ctags version 6.0 will turn on this pseudo tag by default.

🌸 TAG_KIND_SEPARATOR (new in Universal Ctags) 🌸

TBW 🙈 (yeah, another one still cooking)

🌸 TAG_OUTPUT_EXCMD (new in Universal Ctags) 🌸

indicates the specified type of EX command with the --excmd option.

🌸 TAG_OUTPUT_FILESEP (new in Universal Ctags) 🌸

indicates filename separators ("slash" or "backslsh") used in input fields.

Universal Ctags running on MS Windows replaces backslashes with slashes when emitting input fields by default. this pseudo tag is for notifying client tools about that replacement. 📣

see also the description for the --use-slash-as-filename-separator option in ctags(1).

🌸 TAG_OUTPUT_MODE (new in Universal Ctags) 🌸

indicates whether Universal Ctags extended escape sequences are being used ("u-ctags") or not ("e-ctags").

to reduce illegal characters like <Tab> in tags files, Universal Ctags extends the escape sequences that were originally used in Exuberant Ctags, and applies the escaping rules to more fields.

see tags(5) about the escaping rules.

the --output-format option is for choosing the output mode within the tags output format. see ctags(1) about that option.

in "e-ctags" mode, so as not to violate the tags file format described in tags(5), Universal Ctags skips emitting tag entries that include illegal characters like <Tab>. skips them!! just so you know.

in input fields ({tagfile} in tags(5)), we have one more condition for applying the escaping rules: \ characters are not used as filename separators. UNIX-like systems use / for that purpose. on MS Windows, Universal Ctags converts \ in filenames to / by default. so, generally this condition is satisfied. the condition is not satisfied only when you specify --use-slash-as-filename-separator=no on MS Windows. write that down 📝

🌸 TAG_OUTPUT_VERSION (new in Universal Ctags 6.0) 🌸

indicates the language-common interface version of the output:

!_TAG_OUTPUT_VERSION  {current}.{age} /.../

the public interface includes common fields, common extras, and pseudo tags.

the maintainer of Universal Ctags may update the numbers, "{current}" and "{age}", in the same manner as explained in TAG_PARSER_VERSION. so stay tuned 🎀

🌸 TAG_PARSER_VERSION (new in Universal Ctags 6.0) 🌸

indicates the interface version of the parser:

!_TAG_PARSER_VERSION!{language-name}  {current}.{age} /.../

to be continued, bestie — this page keeps going 💖

The public interfaces include kinds, roles, language specific fields, and language specific extras. Bestie, that's the whole squad right there 💅

The maintainer of the parser for "${language-name}" may update the numbers, "{current}" and "{age}" in the following rules:

  • If kinds, roles, language specific fields, and/or language specific extras have been added, removed or changed since last release, increment "{current}".
  • If they have been added since last release, increment "{age}".
  • If they have been removed since last release, set "{age}" to 0.

This concept is based on the versioning in libtool (7.2 Libtool's versioning system <https://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning>.) In Universal Ctags, we simplified the concept with removing "revision" in the versioning in libtool. ✨ Streamlined, as she should be.

Manual pages for languages may document changes that increase the number of "{current}".

TAG_PATTERN_LENGTH_LIMIT (new in Universal Ctags) 🌸

TBW. Literally nothing here yet bestie, we're keeping the seat warm 🫶

TAG_PROC_CWD (new in Universal Ctags) 🌸

Indicates the working directory of ctags during processing. 🐚

This pseudo-tag helps a client tool solve the absolute paths for the input files for tag entries even when they are tagged with relative paths. Like, it's the glow-up from relative to absolute, iykyk.

An example of the pseudo-tags:

$ cat tags
!_TAG_PROC_CWD        /tmp/   //
main  input.c /^int main (void) { return 0; }$/;"     f       typeref:typename:int
...

From the regular tag for "main", the client tool can know the "main" is at input.c. However, it is a relative path. So if the directory where ctags run and the directory where the client tool runs are different, the client tool cannot find input.c from the file system. In that case, TAG_PROC_CWD gives the tool a hint; input.c may be at /tmp. 🎀

TAG_PROGRAM_NAME 🌸

Indicates the name of program generating this tags file. 💖

TAG_PROGRAM_VERSION 🌸

Indicates the version of program generating this tags file. 💖

TAG_ROLE_DESCRIPTION (new in Universal Ctags) 🌸

Indicates the names and descriptions of enabled roles:

!_TAG_ROLE_DESCRIPTION!{language-name}!{kind-name}    {role-name}     /description/

If your tool relies on some roles, refer to the pseudo-tags of this type. Note that a role owned by a disabled kind is not listed even if the role itself is enabled. No cap, it just doesn't show up 💀

REDUNDANT-KINDS 👑

TBW (Write about --fields=+kKzZ)

MULTIPLE-LANGUAGES FOR AN INPUT FILE 🌈

Universal ctags can run multiple parsers. That means a parser, which supports multiple parsers (guest parsers or sub-parsers), may output tags for different languages. It's giving multilingual icon ✨

Guest parsers 🧚

A parser can run guest pursers on the areas in a source file. 👯

Consider the following text as a source file (input.html):

<html><head>
        <script>class MyObject {}</script>
        <style type="text/css">h1.heading { color: red; }</style>
</htad>
<h1 class='heading'>title</h1>
</html>

If a user doesn't specify any extras, Universal ctags emits:

$ ctags -o - input.html
title   input.html      /^<h1 class='heading'>title<\/h1>$/;"   h

These is no issue here. running guest pursers extra is disabled by default. 🙈

If a user enables the running guest parsers extra with specifying --extras=+{guest} or --extras=+g, Universal ctags emits:

$ ctags -o - --extras='{guest}' input.html
MyObject        input.html      /class MyObject {}/;"   c
h1.heading      input.html      /h1.heading { color: red; }/;"  c
title   input.html      /^<h1 class='heading'>title<\/h1>$/;"   h

Universal ctags extracts the language objects for CSS and JavaScript; the HTML parser runs JavaScript parser on the area "<script>...</script>" area and CSS parser on the area "<style ...> ...</style>" area. 🌸

If a client tool assumes that ctags runs one parser for an input file, the tool may tell "MyObject is a class of HTML" and/or "h1.heading is a class of HTML" to its users. c is too few information to tell what is "MyObject" and what is "h1.heading" correctly. The client tool needs more information. 😭

language/l field can be used to show the language for each tag.

$ ctags -o - --extras='{guest}' --fields=+'{language}' input.html
MyObject        input.html      /class MyObject {}/;"   c       language:JavaScript
h1.heading      input.html      /h1.heading { color: red; }/;"  c       language:CSS
title   input.html      /^<h1 class='heading'>title<\/h1>$/;"   h       language:HTML

For some class tools, the language: field provides enough information. Universal ctags can emits more self-descriptive tag file. 💅

Enabling K field with --fields=+K option, Universal ctags uses long-names instead of single-letter to represent kind fields:

$ ctags -o - --extras='{guest}' --fields=+'{language}K' input.html
MyObject        /tmp/input.html /class MyObject {}/;"   class   language:JavaScript
h1.heading      /tmp/input.html /h1.heading { color: red; }/;"  class   language:CSS
title   /tmp/input.html /^<h1 class='heading'>title<\/h1>$/;"   heading1        language:HTML

The long-name representation makes tag files larger. If you want to keep a tag file small, you can make your tool utilize pseudo-tags instead of enabling K field. Universal ctags emits the following line at the beginning of a tags file by default:

$ cat ./tags
...
!_TAG_KIND_DESCRIPTION!CSS      c,class /classes/
...
!_TAG_KIND_DESCRIPTION!HTML     c,class /classes/
!_TAG_KIND_DESCRIPTION!HTML     h,heading1      /H1 headings/
...
!_TAG_KIND_DESCRIPTION!JavaScript       c,class /classes/
...

From the second field of the output, a tool can know the mapping between a single-letter for a kind and a long-name for the kind. 🎀

Universal ctags emits pseudo-tags to tag files by default. However, if you make ctags emit to standard output with -o - or -f - option, ctags doesn't print pseudo-tags. pseudo/p extra forces emitting. 🔥

$ ctags -o - --extras='{guest}{pseudo}' --fields=+'{language}' input.html
...
!_TAG_KIND_DESCRIPTION!CSS      c,class /classes/
...
!_TAG_KIND_DESCRIPTION!HTML     c,class /classes/
!_TAG_KIND_DESCRIPTION!HTML     h,heading1      /H1 headings/
...
!_TAG_KIND_DESCRIPTION!JavaScript       c,class /classes/
...

Sub-parsers 🧚

TBW. Nothing here yet bestie, it's a whole blank canvas 🦋

💅 UTILIZING READTAGS 💅

okay so, first thing first: go read readtags(1) to actually learn how to use readtags, bestie. this section is the deep-lore zone — the notable topics that matter if you're building client tools. the stuff you only learn after getting personally victimized by a shell. 🫶

✨ Build Filter/Sorter Expressions ✨

so readtags recognizes certain escape sequences inside expressions, and that is lowkey a whole thing. for example, say you're searching for a tag that matches a\?b, and you use a filter expression like '(eq? $name "a\?b")'. since \? gets translated into a single ? by readtags, you're actually searching for a?b. surprise! 🎀

another problem, and this one is giving chaos: if your client tool talks to readtags not by subprocess directly, but through a shell, then a single quote appearing in filter expressions (which are themselves wrapped by single quotes) will terminate the expression, produce broken expressions, and may even cause unintended shell injection. not cute. not slay. single quotes can be escaped using '"'"'.

so client tools need to:

  • Replace \ by \\
  • Replace ' by '"'"', if it talks to readtags through a shell.

inside the expressions. and if the expression also contains strings, " in the strings needs to be replaced by \".

another thing to notice (iykyk): missing fields are represented by #f, and applying string operators to them will produce an error. you should always check if a field is missing before applying string operators. see the "Filtering" section in readtags(1) to know how to do this. and run readtags -H filter to see which operators take string arguments. 💖

🌸 Build Filter/Sorter Expressions using Lisp Languages 🌸

client tools written in Lisp could build the expression using lists. prin1 (in Common Lisp style Lisps) and write (in Scheme style Lisps) can translate the list into a string that can be directly used. for example, in EmacsLisp:

(let ((name "hi"))
  (prin1 `(eq? $name ,name)))
=> "(eq\\? $name "hi")"

the "?" is escaped, and readtags can handle it. iconic behavior honestly.

escape sequences produced by write in Scheme style Lisps are exactly those supported by readtags, so any legal readtags expressions can be used. Common Lisp style Lisps may produce escape sequences that are unrecgonized by readtags, like \#, so symbols that contain # can't be used. 😭

readtags provides some aliases for these Lisps, so they should:

  • Use true for #t.
  • Use false for #f.
  • Use nil or () for ().
  • Use (string->regexp "PATTERN") for #/PATTERN/. Use (string->regexp "PATTERN" :case-fold true) for #/PATTERN/i. Notice that string->regexp doesn't require escaping / in the pattern.

notice that if the client tool talks to readtags through a shell, then in the produced string, ' still needs to be replaced by '"'"' to prevent broken expressions and shell injection. yes, again. it's a whole recurring theme. 💀

🦋 Parse Readtags Output 🦋

in the output of readtags, tabs can appear in all field values (like, the tag name itself could contain tabs), which makes it genuinely hard to split the line into fields. so client tools should use the -E option, which keeps the escape sequences in the tags file, so the only field that could contain tabs is the pattern field. periodt.

the pattern field could:

  • Use a line number. It will look like number;" (e.g. 10;").
  • Use a search pattern. It will look like /pattern/;" or ?pattern?;". Notice that the search pattern could contain tabs.
  • Combine these two, like number;/pattern/;" or number;?pattern?;".

these are true for tags files using extended format, which is the default one. the legacy format (i.e. --format=1) doesn't include the semicolons. it's old and barely used, so we won't discuss it here. 🙈

client tools could split the line using the following steps:

  • Find the first 2 tabs in the line, so we get the name and input field.
  • From the 2nd tab:
    • If a / follows, then the pattern delimiter is /.
    • If a ? follows, then the pattern delimiter is ?.
    • If a number follows, then:
      • If a ;/ follows the number, then the delimiter is /.
      • If a ;? follows the number, then the delimiter is ?.
      • If a ;" follows the number, then the field uses only line number, and there's no pattern delimiter (since there's no regex pattern). In this case the pattern field ends at the 3rd tab.
  • After the opening delimiter, find the next unescaped pattern delimiter, and that's the closing delimiter. It will be followed by ;" and then a tab. That's the end of the pattern field. By "unescaped pattern delimiter", we mean there's an even number (including 0) of backslashes before it.
  • From here, split the rest of the line into fields by tabs.

then, the escape sequences in fields other than the pattern field should be translated. see "Proposal" in tags(5) to know about all the escape sequences. ⭐

👑 Make Use of the Pattern Field 👑

the pattern field specifies how to find a tag in its source file. the code generating this field seems to have a long history, so there are some pitfalls and it's a bit hard to handle. a client tool could simply require the line: field and jump to the line it specifies, to avoid using the pattern field. but anyway, we'll discuss how to make the best use of it here.

take the words here merely as suggestions, not standards. a client tool could definitely develop better (or simpler) ways to use the pattern field. do your own thing, bestie. 💅

from the last section, we know the pattern field could contain a line number and a search pattern. when it only contains the line number, handling it is easy: you simply go to that line.

the search pattern resembles an EX command, but as we'll see later, it's actually not a valid one, so some manual work are required to process it.

the search pattern could look like /pat/, called "forward search pattern", or ?pat?, called "backward search pattern". using a search pattern means even if the source file is updated, as long as the part containing the tag doesn't change, we could still locate the tag correctly by searching. that's the whole point. that's the vibe. 🔥

when the pattern field only contains the search pattern, you just search for it. the search direction (forward/backward) doesn't matter, as it's decided solely by whether the -B option is enabled, and not the actual context. you could always start the search from say the beginning of the file.

when both the search pattern and the line number are presented, you could make good use of the line number, by going to the line first, then searching for the nearest occurrence of the pattern. a way to do this is to search both forward and backward for the pattern, and when there is an occurrence on both sides, go to the nearer one.

what's good about this is when there are multiple identical lines in the source file (e.g. the COMMON block in Fortran), this could help us find the correct one, even after the source file is updated and the tag position is shifted by a few lines. main character energy, honestly. ✨

now let's discuss how to search for the pattern. after you trim the / or ? around it, the pattern resembles a regex pattern. it should be a regex pattern, as required by being a valid EX command, but it's actually not, as you'll see below.

it could begin with a ^, which means the pattern starts from the beginning of a line. it could also end with an unescaped $ which means the pattern ends at the end of a line. let's keep this information, and trim them too.

now the remaining part is the actual string containing the tag. some characters are escaped:

  • \.
  • $, but only at the end of the string.
  • /, but only in forward search patterns.
  • ?, but only in backward search patterns.

you need to unescape these to get the literal string. now you could convert this literal string to a regexp that matches it (by escaping, like re.escape in Python or regexp-quote in Elisp), and assemble it with ^ or $ if the pattern originally has it, and finally search for the tag using this regexp. slay. 🎀

💜 Remark: About a Previous Format of the Pattern Field 💜

in some earlier versions of Universal Ctags, the line number in the pattern field is the actual line number minus one, for forward search patterns; or plus one, for backward search patterns. the idea is to resemble an EX command: you go to the line, then search forward/backward for the pattern, and you can always find the correct one. but this denies the purpose of using a search pattern: to tolerate file updates. 😭

for example, the tag is at line 50, according to this scheme, the pattern field should be:

49;/pat/;"

then let's assume that some code above are removed, and the tag is now at line 45. now you can't find it if you search forward from line 49. rip.

due to this reason, Universal Ctags turns to use the actual line number. a client tool could distinguish them by the TAG_OUTPUT_EXCMD pseudo tag, it's "combine" for the old scheme, and "combineV2" for the present scheme. but probably there's no need to treat them differently, since "search for the nearest occurrence from the line" gives good result on both schemes. 🫶

🌈 JSON OUTPUT 🌈

see ctags-json-output(5). short and sweet, we love that. ⭐

💖 CHANGES 💖

Version 6.0

  • ctags enables TAG_KIND_DESCRIPTION, TAG_ROLE_DESCRIPTION, TAG_FIELD_DESCRIPTION, and TAG_EXTRA_DESCRIPTION pseudo tags by default.
  • TAG_PARSER_VERSION is introduced.

🎀 SEE ALSO 🎀

ctags(1), ctags-lang-python(7), ctags-incompatibilities(7), tags(5), ctags-json-output(5), readtags(1), 7.2 Libtool's versioning system (https://www.gnu.org/software/libtool/manual/libtool.html#Libtool-versioning)

and that's a wrap bestie!! this page is version 6.2.1 of ctags-client-tools(7) — go forth and build ur client tool, you've got this, no cap 💅✨🦋

📦 where this page comes from