ctags-client-tools

package: universal-ctags

title: ctags-client-tools(7)

text:
# ctags-client-tools(7)

## NAME
ctags-client-tools - Hints for developing a tool using ctags command and tags output

## SYNOPSIS

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

## DESCRIPTION
Client tool means a tool running the ctags command and/or reading a tags file generated by ctags command. This man page gathers hints for people who develop client tools.

## PSEUDO-TAGS
Pseudo-tags, stored in a tag file, indicate how ctags generated the tags file: whether the tags file is sorted or not, which version of tags file format is used, the name of tags generator, and so on. The opposite term for pseudo-tags is regular-tags. A regular-tag is for a language object in an input file. A pseudo-tag is for the tags file itself. Client tools may use pseudo-tags as reference for processing regular-tags.

A pseudo-tag is stored in a tags file in the same format as regular-tags as described in tags(5), except that pseudo-tag names are prefixed with "!_". For the general information about pseudo-tags, see "TAG FILE INFORMATION" in tags(5).

An example of a pseudo tag:

```
!_TAG_PROGRAM_NAME      Universal Ctags /Derived from Exuberant Ctags/
```

The value, "Universal Ctags", associated with the pseudo tag TAG_PROGRAM_NAME, is used in the field for input file. The description, "Derived from Exuberant Ctags", is used in the field for pattern.

Universal Ctags extends the naming scheme of the classical pseudo-tags available in Exuberant Ctags for emitting language specific information as pseudo tags:

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

The language-name is appended to the pseudo-tag name with a separator, "!".

An example of pseudo tag with a language suffix:

```
!_TAG_KIND_DESCRIPTION!C        f,function      /function definitions/
```

This pseudo-tag says "the function kind of C language is enabled when generating this tags file." --pseudo-tags is the option for enabling/disabling individual pseudo-tags. When enabling/disabling a pseudo tag with the option, specify the tag name only TAG_KIND_DESCRIPTION, without the prefix ("!_") or the suffix ("!C").

### Options for Pseudo-tags
--extras=+p (or --extras=+{pseudo})

Forces writing pseudo-tags. ctags emits pseudo-tags by default when writing tags to a regular file (e.g. "tags'.) However, when specifying -o - or -f - for writing tags to standard output, ctags doesn't emit pseudo-tags. --extras=+p or --extras=+{pseudo} will force pseudo-tags to be written.

--list-pseudo-tags

Lists available types of pseudo-tags and shows whether they are enabled or disabled. Running ctags with --list-pseudo-tags option lists available pseudo-tags. Some of pseudo-tags newly introduced in Universal Ctags project are disabled by default. Use --pseudo-tags=... to enable them.

--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 --pseudo-tags= option.

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

If a name is preceded by either the '+' or '-' characters, that tags'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})

Attach "extras:pseudo" field to pseudo-tags. An example of pseudo tags with the 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 cannot distinguish whether the tag is a regular-tag or pseudo-tag. The fields attached with this option help the tool distinguish them.

### List of notable pseudo-tags
Running ctags with --list-pseudo-tags option lists available types of pseudo-tags with short descriptions. This subsection shows hints for using notable ones.

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 the tags file that doesn't include expected extras, and raise an error in an early stage of processing.

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 "{anonymous}", "{fileScope}", "{pseudo}", and "{subparser}" extras are enabled from the output.

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 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 "{file}", "{input}", "{name}", "{pattern}", and "{typeref}" fields are enabled from the output. The fields are common in languages. In addition to the common fields, the tool can known "{macrodef}" field of C language is also enabled.

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

TAG_FILE_ENCODING (new in Universal Ctags)

TBW

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 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 suffix.

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 "{function}", "{member}", and "{variable}" kinds of C language are enabled from the output.

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

TAG_KIND_SEPARATOR (new in Universal Ctags)

TBW

TAG_OUTPUT_EXCMD (new in Universal Ctags)

Indicates the specified type of EX command with --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 this replacement to client tools.

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

TAG_OUTPUT_MODE (new in Universal Ctags)

Indicates whether using Universal Ctags extended escape sequences ("u-ctags") or not ("e-ctags"). To reduce illegal characters like <Tab> in tags files, Universal Ctags extends the escape sequences originally used in Exuberant Ctags, and applies the escaping rules to more fields.

See tags(5) about the escaping rules.

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

In "e-ctags" mode, for not violating the tags file format described in tags(5), Universal Ctags skips emitting tag entries including illegal characters like <Tab>.

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 the 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.

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, pseudo tags.

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

TAG_PARSER_VERSION (new in Universal Ctags 6.0)

Indicates the interface version of the parser:

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

The public interfaces include kinds, roles, language specific fields, and language specific extras.

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.

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

TAG_PATTERN_LENGTH_LIMIT (new in Universal Ctags)

TBW

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.

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.

## 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.

### 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

## UTILIZING READTAGS
See readtags(1) to know how to use readtags. This section is for discussing some notable topics for client tools.

### Build Filter/Sorter Expressions
Certain escape sequences in expressions are recognized by readtags. For example, when searching for a tag that matches a\?b, if using a filter expression like '(eq? $name "a\?b")', since \? is translated into a single ? by readtags, it actually searches for a?b.

Another problem is: If the client tools talks to readtags not by subprocess directly, but through a shell, then if a single quote appear in filter expressions (which is also wrapped by single quotes), it terminates the expression, producing broken expressions, and may even cause unintended shell injection. 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. If the expression also contains strings, " in the strings needs to be replaced by \".

Another thing to notice is that 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. 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.

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.

### Parse Readtags Output
In the output of readtags, tabs can appear in all field values (e.g., the tag name itself could contain tabs), which makes it hard to split the line into fields. 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.

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.

You should take the words here merely as suggestions, and not standards. A client tool could definitely develop better (or simpler) ways to use the pattern field.

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.

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 a 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.

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.

### 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.

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).

## 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>


ctags-faq

title: ctags-faq(7)

summary: Universal Ctags FAQ

text:
# ctags-faq(7)

## NAME
ctags-faq - Universal Ctags FAQ

This is the Universal Ctags FAQ (Frequently-Asked Questions). It is based on Exuberant Ctags FAQ <http://ctags.sourceforge.net/faq.html>

### Contents
•

DESCRIPTION

- What is the difference between Universal Ctags and Exuberant Ctags?

- How can I avoid having to specify my favorite option every time?

- What are these strange bits of text beginning with ;" which follow many of the lines in the tag file?

- Why can't I jump to class::member?

- Why do I end up on the wrong line when I jump to a tag?

- How do I jump to the tag I want instead of the wrong one by the same name?

- How can I locate all references to a specific function or variable?

- Why does appending tags to a tag file tag so long?

- How should I set up tag files for a multi-level directory hierarchy?

- Does Universal Ctags support Unicode file names?

- Why does zsh cause "zsh: no matches found" error?

- SEE ALSO

- AUTHOR

## DESCRIPTION

### What is the difference between Universal Ctags and Exuberant Ctags?
Universal Ctags is an unofficial fork of Exuberant Ctags. The differences are summarized in ctags-incompatibilities(7) man page.

The most notable one is that Universal Ctags doesn't read ~/.ctags file. Instead, it reads *.ctags under ~/.ctags.d directory.

### How can I avoid having to specify my favorite option every time?
Either by setting the environment variable CTAGS to your custom options, or putting them into a ~/.ctags.d/anyname.ctags file in your home directory.

### What are these strange bits of text beginning with ;" which follow many of the lines in the tag file?
These are extension flags. They are added in order to provide extra information about the tag that may be utilized by the editor in order to more intelligently handle tags. They are appended to the EX command part of the tag line in a manner that provides backwards compatibility with existing implementations of the Vi editor. The semicolon is an EX command separator and the double quote begins an EX comment. Thus, the extension flags appear as an EX comment and should be ignored by the editor when it processes the EX command.

Some non-vi editors, however, implement only the bare minimum of EX commands in order to process the search command or line number in the third field of the tag file. If you encounter this problem, use the option --format=1 to generate a tag file without these extensions (remember that you can set the CTAGS environment variable to any default arguments you wish to supply). Then ask the supplier of your editor to implement handling of this feature of EX commands.

### Why can't I jump to class::member?
Because, by default, ctags only generates tags for the separate identifiers found in the source files. If you specify the --extra=+q option, then ctags will also generate a second, class-qualified tag for each class member (data and function/method) in the form class::member for C++, and in the form class.method for Eiffel and Java.

### Why do I end up on the wrong line when I jump to a tag?
By default, ctags encodes the line number in the file where macro (#define) tags are found. This was done to remain compatible with the original UNIX version of ctags. If you change the file containing the tag without rebuilding the tag file, the location of tag in the tag file may no longer match the current location.

In order to avoid this problem, you can specify the option --excmd=p, which causes ctags to use a search pattern to locate macro tags. I have never uncovered the reason why the original UNIX ctags used line numbers exclusively for macro tags, but have so far resisted changing the default behavior of Exuberant (and Universal) Ctags to behave differently.

### How do I jump to the tag I want instead of the wrong one by the same name?
A tag file is simple a list of tag names and where to find them. If there are duplicate entries, you often end up going to the wrong one because the tag file is sorted and your editor locates the first one in the tag file.

Standard Vi provides no facilities to alter this behavior. However, Vim has some nice features to minimize this problem, primarily by examining all matches and choosing the best one under the circumstances. Vim also provides commands which allow for selection of the desired matching tag.

### How can I locate all references to a specific function or variable?
There are several packages already available which provide this capability. Namely, these are: GLOBAL source code tag system, GNU id-utils, cscope, and cflow. As of this writing, they can be found in the following locations:

- GLOBAL: <http://www.gnu.org/software/global>

- id-utils: <http://www.gnu.org/software/idutils/idutils.html>

- cscope: <http://cscope.sourceforge.net>

- cflow: <ftp://www.ibiblio.org/pub/Linux/devel/lang/c>

### Why does appending tags to a tag file tag so long?
Sometimes, in an attempt to build a global tag file for all source files in a large source tree of many directories, someone will make an attempt to run ctags in append (-a) mode on every directory in the hierarchy. Each time ctags is invoked, its default behavior is to sort the tag file once the tags for that execution have been added. As the cumulative tag file grows, the sort time increases arithmetically.

The best way to avoid this problem (and the most efficient) is to make use of the --recurse (or -R) option of ctags by executing the following command in the root of the directory hierarchy (thus running ctags only once):

```
ctags -R
```

If you really insist on running ctags separately on each directory, you can avoid the sort pass each time by specifying the option --sort=no. Once the tag file is completely built, use the sort command to manually sort the final tag file, or let the final invocation of ctags sort the file.

### How should I set up tag files for a multi-level directory hierarchy?
There are a few ways of approaching this:

1.

A local tag file in each directory containing only the tags for source files in that directory.

2.

One single big, global tag file present in the root directory of your hierarchy, containing all tags present in all source files in the hierarchy.

3.

A local tag file in each directory containing only the tags for source files in that directory, in addition to one single global tag file present in the root directory of your hierarchy, containing all non-static tags present in all source files in the hierarchy.

4.

A local tag file in each directory of the hierarchy, each one containing all tags present in source files in that directory and all non-static tags in every directory below it (note that this implies also having one big tag file in the root directory of the hierarchy).

Each of these approaches has its own set of advantages and disadvantages, depending upon your particular conditions. Which approach is deemed best depends upon the following factors:

A.

The ability of your editor to use multiple tag files. If your editor cannot make use of multiple tag files (original vi implementations could not), then one large tag file is the only way to go if you ever desire to jump to tags located in other directories. If you never need to jump to tags in another directory (i.e. the source in each directory is entirely self-contained), then a local tag file in each directory will fit your needs.

B.

The time is takes for your editor to look up a tag in the tag file. The significance of this factor depends upon the size of your source tree and on whether the source files are located on a local or remote file system. For source and tag files located on a local file system, looking up a tag is not as big a hit as one might first imagine, since vi implementations typically perform a binary search on a sorted tag file. This may or may not be true for the editor you use. For files located on a remote file system, reading a large file is an expensive operation.

C.

Whether or not you expect the source code to change and the time it takes to rebuild a tag file to account for changes to the source code. While Universal Ctags is particularly fast in scanning source code (around 1-2 MB/sec), a large project may still result in objectionable delays if one wishes to keep their tag file(s) up to date on a frequent basis, or if the files are located on a remote file system.

D.

The presence of duplicate tags in the source code and the ability to handle them. The impact of this factor is influenced by the following three issues:

1.

How common are duplicate tags in your project?

2.

Does your editor provide any facilities for dealing with duplicate tags? While standard vi does not, many modern vi implementations, such as Vim have good facilities for selecting the desired match from the list of duplicates. If your editor does not support duplicate tags, then it will typically send you to only one of them, whether or not that is the one you wanted (and not even notifying you that there are other potential matches).

3.

What is the significance of duplicate tags? For example, if you have two tags of the same name from entirely isolated software components, jumping first to the match found in component B while working in component A may be entirely misleading, distracting or inconvenient (to keep having to choose which one if your editor provides you with a list of matches). However, if you have two tags of the same name for parallel builds (say two initialization routines for different hosts), you may always want to specify which one you want.

Of the approaches listed above, I tend to favor Approach 3. My editor of choice is Vim, which provides a rich set of features for handling multiple tag files, which partly influences my choice. If you are working with source files on a remote file system, then I would recommend either Approach 3 or Approach 4, depending upon the hit when reading the global tag file.

The advantages of Approach 3 are many (assuming that your editor has the ability to support both multiple tag files and duplicate tags). All lookups of tag located in the current directory are fast and the local tag file can be quickly and easily regenerated in one second or less (I have even mapped a keystroke to do this easily). A lookup of a (necessarily non-static) tag found in another directory fails a lookup in the local tag file, but is found in the global tag file, which satisfies all cross-directory lookups. The global tag file can be automatically regenerated periodically with a cron job (and perhaps the local tag files also).

Now I give an example of how you would implement Approach 3. Means of implementing the other approaches can be performed in a similar manner.

Here is a visual representation of an example directory hierarchy:

```
project
`-----misccomp
|       `...
`-----sysint

        `-----client

        |       `-----hdrs

        |       `-----lib

        |       `-----src

        |       `-----test

        `-----common

        |       `-----hdrs

        |       `-----lib

        |       `-----src

        |       `-----test

        `-----server

                `-----hdrs

                `-----lib

                `-----src

                `-----test
```

Here is a recommended solution (conceptually) to build the tag files:

1.

Within each of the leaf nodes (i.e. hdrs, lib, src, test) build a tag file using "ctags *.[ch]". This can be easily be done for the whole hierarchy by making a shell script, call it dirtags, containing the following lines:

```
#!/bin/sh
cd $1
ctags *
```

Now execute the following command:

```
find * -type d -exec dirtags {} \;
```

These tag files are trivial (and extremely quick) to rebuild while making changes within a directory. The following Vim key mapping is quite useful to rebuild the tag file in the directory of the current source file:

```
:nmap ,t :!(cd %:p:h;ctags *.[ch])&<CR><CR>
```

2.

Build the global tag file:

```
cd ~/project
ctags --file-scope=no -R
```

thus constructing a tag file containing only non-static tags for all source files in all descendent directories.

3.

Configure your editor to read the local tag file first, then consult the global tag file when not found in the local tag file. In Vim, this is done as follows:

```
:set tags=./tags,tags,~/project/tags
```

If you wish to implement Approach 4, you would need to replace the dirtags script of step 1 with the following:

```
#!/bin/sh
cd $1
ctags *
# Now append the non-static tags from descendent directories
find * -type d -prune -print | ctags -aR --file-scope=no -L-
```

And replace the configuration of step 3 with this:

```
:set tags=./tags;$HOME,tags
```

As a caveat, it should be noted that step 2 builds a global tag file whose file names will be relative to the directory in which the global tag file is being built. This takes advantage of the Vim tagrelative option, which causes the path to be interpreted a relative to the location of the tag file instead of the current directory. For standard vi, which always interprets the paths as relative to the current directory, we need to build the global tag file with absolute path names. This can be accomplished by replacing step 2 with the following:

```
cd ~/project
ctags --file-scope=no -R `pwd`
```

### Does Universal Ctags support Unicode file names?
Yes, Unicode file names are supported on unix-like platforms (Linux, macOS, Cygwin, etc.).

However, on MS Windows, you need to use Windows 10 version 1903 or later to use Unicode file names. (This is an experimental feature, though.) On older versions on Windows, Universal Ctags only support file names represented in the current code page. If you still want to use Unicode file names on them, use Cygwin or MSYS2 version of Universal Ctags as a workaround.

### Why does zsh cause "zsh: no matches found" error?
zsh causes error on the following cases;

```
ctags --extra=+* ...
ctags --exclude=foo/* ...
```

This is the 2nd most significant incompatibility feature of zsh.

Cited from "Z-Shell Frequently-Asked Questions", "2.1: Differences from sh and ksh <http://zsh.sourceforge.net/FAQ/zshfaq02.html> ";

... The next most classic difference is that unmatched glob patterns cause the command to abort; set NO_NOMATCH for those.

You may add "setopt nonomatch" on your ~/.zshrc. Or you can escape glob patterns with backslash;

```
ctags --extra=+\* ...
ctags --exclude=foo/\* ...
```

Or quote them;

```
ctags '--extra=+*' ...
ctags '--exclude=foo/*' ...
```

## SEE ALSO
The official Universal Ctags web site at:

<https://ctags.io/>

ctags(1), tags(5)

## AUTHOR
This FAQ is based on Exuberant Ctags FAQ <http://ctags.sourceforge.net/faq.html>

by Darren Hiebert and <vberthoux@users.sourceforge.net>

Universal Ctags project: <https://ctags.io/>

branch: sisyphus


ctags-incompatibilities

title: ctags-incompatibilities(7)

text:
# ctags-incompatibilities(7)

## NAME
ctags-incompatibilities - Incompatibilities between Universal Ctags and Exuberant Ctags

## SYNOPSIS

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

## DESCRIPTION
This page describes major incompatible changes introduced to Universal Ctags forked from Exuberant Ctags.

### Option files loading at starting up time (preload files)
Universal Ctags doesn't load ~/.ctags at starting up time. File paths for preload files are changed. See "FILES" section of ctags(1).

### Environment variables for arranging command lines
Universal Ctags doesn't read CTAGS and/or ETAGS environment variables.

### Behavior when --excmd=mixed is given
Exuberant Ctags uses line numbers as addresses for C preprocessor macro definition tags. Universal Ctags uses patterns for the tags.

### Ordering in a command line
The command line format of Universal Ctags is "ctags [options] [source_file(s)]" following the standard POSIX convention.

Exuberant Ctags accepts a option following a source file.

```
$ ctags -o - foo.c --list-kinds=Sh
f  functions
```

Universal Ctags warns and ignores the option --list-kinds=Sh as follows.

```
$ ctags -o - foo.c --list-kinds=Sh
ctags: Warning: cannot open input file "--list-kinds=Sh" : No such file or directory
a       foo.c   /^void a () {}$/;"      f       typeref:typename:void
b       foo.c   /^void b () {}$/;"      f       typeref:typename:void
```

### The order of application of patterns and extensions in --langmap
When applying mappings for a name of given source file, Exuberant Ctags tests file name patterns AFTER file extensions (e-map-order). Universal Ctags does this differently; it tests file name patterns BEFORE file extensions (u-map-order).

This incompatible change is introduced to deal with the following situation:

- build.xml as a source file,

- The Ant parser declares it handles a file name pattern build.xml, and

- The XML parser declares it handles a file extension .xml.

Which parser should be used for parsing build.xml? The assumption of Universal Ctags is the user may want to use the Ant parser; the file name pattern it declares is more specific than the file extension that the XML parser declares. However, e-map-order chooses the XML parser.

So Universal Ctags uses the u-map-order even though it introduces an incompatibility.

--list-map-extensions=<language> and --list-map-patterns=<language> options are helpful to verify and the file extensions and the file name patterns of given <language>.

### Remove --file-tags and --file-scope options
Even in Exuberant Ctags, --file-tags is not documented in its man page. Instead of specifying --file-tags or --file-tags=yes, use --extras=+f or --extras=+{inputFile}.

Instead of specifying --file-tags=no, use --extras=-f or --extras=-{inputFile}.

Universal Ctags introduces F/fileScope extra as the replacement for --file-scope option.

Instead of specifying --file-tags or --file-tags=yes, use --extras=+F or --extras=+{fileScope}.

Instead of specifying --file-tags=no, use --extras=-F or --extras=-{fileScope}.

### Language name defined with --langdef=name option
The characters you can use are more restricted than Exuberant Ctags. For more details, see the description of --langdef=name in ctags-optlib(7).

### Obsoleting --<LANG>-kinds option
Some options have <LANG> as parameterized parts in their name like --foo-<LANG>=... or --<LANG>-foo=.... The most of all such options in Exuberant Ctags have the former form, --foo-<LANG>=.... The exception is --<LANG>-kinds.

Universal Ctags uses the former form for all <LANG> parameterized option. Use --kinds-<LANG> instead of --<LANG>-kinds in Universal Ctags. --<LANG>-kinds still works but it will be removed in the future.

The former form may be friendly to shell completion engines.

### Disallowing to define a kind with file as name
The kind name file is reserved. Using it as part of kind spec in --regex-<LANG> option is now disallowed.

### Disallowing to define a kind with 'F' as letter
The kind letter 'F' is reserved. Using it as part of a kind spec in --regex-<LANG> option is now disallowed.

### Disallowing to use other than alphabetical character as kind letter
Exuberant Ctags accepts a character other than alphabetical character as kind letter in --regex-<LANG>=... option. Universal Ctags accepts only an alphabetical character.

### Acceptable characters as parts of a kind name
Exuberant Ctags accepts any character as a part of a kind name defined with --regex-<LANG>=/regex/replacement/kind-spec/.

Universal Ctags accepts only an alphabetical character as the initial letter of a kind name. Universal Ctags accepts only an alphabetical character or numerical character as the rest letters.

An example:

```
--regex-Foo=/abstract +class +([a-z]+)/\1/a,abstract class/i
```

Universal Ctags rejects this because the kind name, abstract class, includes a whitespace character.

This requirement is for making the output of Universal Ctags follow the tags file format.

### A combination of a kind letter and a kind name
In Universal Ctags, the combination of a kind letter and a kind name must be unique in a language.

You cannot define more than one kind reusing a kind letter with different kind names. You cannot define more than one kind reusing a kind name with different kind letters.

An example:

```
--regex-Foo=/abstract +class +([a-z]+)/\1/a,abstractClass/i
--regex-Foo=/attribute +([a-z]+)/\1/a,attribute/i
```

Universal Ctags rejects this because the kind letter, 'a', used twice for defining a kind abstractClass and attribute.

### Using numerical character in the name part of tag tagfield
The version 2 tags file format, the default output format of Exuberant Ctags, accepts only alphabetical characters in the name part of tag tagfield.

Universal Ctags introduces an exception to this specification; it may use numerical characters in addition to alphabetical characters as the letters other than initial letter of the name part.

The kinds heading1, heading2, and heading3 in the HTML parser are the examples.

### Truncating the pattern for long input lines
To prevent generating overly large tags files, a pattern field is truncated, by default, when its size exceeds 96 bytes. A different limit can be specified with --pattern-length-limit=N. Specifying 0 as N results no truncation as Exuberant Ctags does not.

### Kind letters and names
A kind letter 'F' and a kind name file are reserved in the main part. A parser cannot have a kind conflicting with these reserved ones. Some incompatible changes are introduced to follow the above rule.

- Cobol's file kind is renamed to fileDesc because the kind name file is reserved.

- Ruby's 'F' (singletonMethod) is changed to 'S'.

- SQL's 'F' (field) is changed to 'E'.

## SEE ALSO
ctags(1), ctags-optlib(7), and tags(5).


ctags-lang-asm

title: ctags-lang-asm(7)

text:
# ctags-lang-asm(7)

## NAME
ctags-lang-asm - Random notes about tagging Assembly language source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Asm ...
ctags ... --language-force=Asm ...
ctags ... --map-Asm=+.asm ...
ctags ... --map-Asm=+.ASM ...
ctags ... --map-Asm=+.s ...
ctags ... --map-Asm=+.S ...
```

## DESCRIPTION
This man page gathers random notes about tagging assembly language source code.

The parser of Universal Ctags has been extended to support the source code to be processed with GNU assembler (Gas).

## PARAMETERS
The Asm parser has some parameters for adapting it to different assembler implementations.

Writing a parser for assembly language source code is not easy because the syntax for the language differ depending on the implementations of assemblers and target CPU architectures. For example, in NASM, ; is a starter of a line comment. On the other hand, in Gas for i386, ; is a line separator. The parameters explained this man page are for mitigating the gaps of syntax.

Use --param-Asm.{parameter}={value} option for adjusting the value for a parameter. For example:

```
$ ctags ... --param-Asm.runCPreProcessor=false ...
```

This command line sets false to runCPreProcessor parameter.

--list-params=Asm lists available parameters available in the Asm parser.

### runCPreProcessor: running C preprocessor
By default, the CPreProcessor parser processes the assembly language source code before the Asm parser does.

The main effects of running the CPreProcessor parser;

- lines started from // are stripped as comments,

- areas surrounded by the pair of /* and */ are stripped as comments, and

- macros defined with #define are extracted as tags.

Set runCPreProcessor to false for disabling the CPreProcessor parser running before the Asm parser.

### commentCharsAtBOL: adjusting line comment starter at the beginning of line
By default, the Asm parser ignores lines starting from ;, *, or @ as comments. // is also ignored if runCPreProcessor is true.

commentCharsAtBOL is for changing the characters for line comments. BOL is acronym standing for "the beginning of line." The characters act as comment starters only if they are at the beginning of lines.

The next example if for assembler input using ! and > as the comment starter:

```
$ ctags ... --param-Asm.commentCharsAtBOL='!>' ...
```

### commentCharsInMOL: adjusting line comment starter in the middle of line
Some dialects of assemblers support comments starting from the middle of line. A ; character starts a comment anywhere on the line in Gas for CRIS for example.

commentCharsInMOL is for specifying the character for line comments. MOL is acronym standing for "the middle of line." Unlike characters specified with commentCharsAtBOL, the characters specified with commentCharsInMOL act as comment starts even if they are in the middle of lines.

By default, the Asm parser has no commentCharsInMOL characters.

### extraLinesepChars: adding line separators
The Asm parser processes its input line-oriented way. By default, the parser recognizes n as a line separator. extraLinesepChars is for adding more line separators.

In Gas for AArch64, the ; character can be used as line separators. The next example for adjusting the Asm parser to the extra line separator:

```
$ ctags ... --param-Asm.extraLinesepChars=';' ...
```

## EXPANDING C PREPROCESSOR MACROS
The Asm parser has the ability to expand C preprocessor macros before parsing.

NOTE:

Don't confuse C preprocessor macros and assembler implementation specific macros. The Asm parser expands only C preprocessor macros.

Specifying following options are must for expansion:

```
--param-Asm.runCPreProcessor=true
--fields=+{signature}
--fields-CPreProcessor=+{macrodef}
```

With the above options, the parser expands macros defined in command line with -D option. See ctags(1) about the way to define a macro with the -D option.

With --param-CPreProcessor._expand=1 option, the parser expands macros defined in the current input file in addition to macros defined with the -D option.

Though the parser expands macros, the parser doesn't extract language objects like labels as you expect. You must adjust the parser specific parameters to utilize the macro expansion feature effectively. See

### An example of macro expansion
"input.S"

```
#define ENTRY(LABEL) .global LABEL      ;\
LABEL
ENTRY(main):

        nop
```

"output.tags" with "--options=NONE -o - --param-Asm.useCPreProcessor=1 --param-CPreProcessor._expand=1 --fields=+{signature} --fields-CPreProcessor=+{macrodef} --param-Asm.extraLinesepChars=; --fields-CPreProcessor=+{macrodef} input.S"

```
ENTRY   input.S /^#define ENTRY(/;"     d       file:   signature:(LABEL)       macrodef:.global LABEL ;LABEL
main    input.S /^ENTRY(main):$/;"      l
main    input.S /^ENTRY(main):$/;"      s
```

The definition of ENTRY assumes ; is a line separator in the host assembly language. --param-Asm.extraLinesepChars=; is for satisfying the assumption in ctags side.

### Known limitations
The parser has no ability to expand the macros defined outside of the current input file. The parser doesn't consider #undef when expanding.

## VERSIONS

### Change since "0.0"
•

The kind section is deleted. The section specified with .section directive as tagged as placement role of section kind of Asm language. These kind and role are deleted. Instead, it is tagged as destination role of inputSection kind of LdScript language.

## SEE ALSO
ctags(1), ctags-lang-asm(7), Info entries for GNU assembler


ctags-lang-autoit

title: ctags-lang-autoit(7)

text:
# ctags-lang-autoit(7)

## NAME
ctags-lang-autoit - Random notes about tagging AutoIt source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+AutoIt ...
ctags ... --language-force=AutoIt ...
ctags ... --map-AutoIt=+.au3 ...
```

## DESCRIPTION
This man page gathers random notes about tagging AutoIt source code.

## VERSIONS

### Change since "0.0"
•

Drop $ from tags for variables names.

## SEE ALSO
ctags(1)


ctags-lang-automake

title: ctags-lang-automake(7)

text:
# ctags-lang-automake(7)

## NAME
ctags-lang-automake - Random notes about tagging Automake source code (Makefile.am) with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Automake ...
ctags ... --language-force=Automake ...
ctags ... --map-Automake=+.am ...
```

## DESCRIPTION
This man page gathers random notes about tagging Automake source code (Makefile.am).

## VERSIONS

### Change since "0.0"

- Add canonicalizedName extra.

- Add pseudodir kind.

## SEE ALSO
ctags(1)


ctags-lang-c

title: ctags-lang-c(7)

text:
# ctags-lang-c(7)

## NAME
ctags-lang-c - Random notes about tagging C source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+C ...
ctags ... --language-force=C ...
ctags ... --map-C=+.c ...
```

## DESCRIPTION
This man page gathers random notes about tagging C source code.

## VERSIONS

### Change since "0.0"

- New role foreigndecl for function kind

- New role foreigndecl for struct kind

- New field section

- New field alias

## SEE ALSO
ctags(1), ctags-lang-ldscript(7), The new C/C++ parser <https://docs.ctags.io/en/latest/parser-cxx.html>

( <https://docs.ctags.io/en/latest/parser-cxx.html> )


ctags-lang-c++

title: ctags-lang-c++(7)

text:
# ctags-lang-c++(7)

## NAME
ctags-lang-c++ - Random notes about tagging C++ source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+C++ ...
ctags ... --language-force=C++ ...
ctags ... --map-C++=+.c++  ...
ctags ... --map-C++=+.cc  ...
ctags ... --map-C++=+.cpp  ...
ctags ... --map-C++=+.h  ...

...
```

## DESCRIPTION
This man page gathers random notes about tagging C++ source code.

## VERSIONS

### Change since "0.0"

- New field section

- New field alias

### Change since "1.1"

- New kinds module and partition

- New roles imported and exported for header kind

## SEE ALSO
ctags(1), ctags-lang-ldscript(7), The new C/C++ parser <https://docs.ctags.io/en/latest/parser-cxx.html>

( <https://docs.ctags.io/en/latest/parser-cxx.html> )


ctags-lang-clojure

title: ctags-lang-clojure(7)

text:
# ctags-lang-clojure(7)

## NAME
ctags-lang-clojure - Random notes about tagging Clojure source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Clojure ...
ctags ... --language-force=Clojure ...
ctags ... --map-Clojure=+.clj ...
ctags ... --map-Clojure=+.cljs ...
ctags ... --map-Clojure=+.cljc ...
```

## DESCRIPTION
This man page gathers random notes about tagging Clojure source code.

## VERSIONS

### Change since "0.0"

- Add unknown kind.

- Add definer field.

## SEE ALSO
ctags(1)


ctags-lang-cuda

title: ctags-lang-cuda(7)

text:
# ctags-lang-cuda(7)

## NAME
ctags-lang-cuda - Random notes about tagging CUDA source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+CUDA ...
ctags ... --language-force=CUDA ...
ctags ... --map-CUDA=+.cu  ...
ctags ... --map-CUDA=+.cuh  ...
```

## DESCRIPTION
This man page gathers random notes about tagging CUDA source code.

## VERSIONS

### Change since "0.0"

- New field section

- New field alias

## SEE ALSO
ctags(1), ctags-lang-ldscript(7), The new C/C++ parser <https://docs.ctags.io/en/latest/parser-cxx.html>

( <https://docs.ctags.io/en/latest/parser-cxx.html> )


ctags-lang-elm

title: ctags-lang-elm(7)

text:
# ctags-lang-elm(7)

## NAME
ctags-lang-elm - Random notes about tagging Elm source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Elm ...
ctags ... --language-force=Elm ...
ctags ... --map-Elm=+.elm ...
```

## DESCRIPTION
The Elm parser is a PEG parser using PackCC, which is part of the ctags infrastructure. It should correctly process all top level statements, however there is a limitation with functions embedded in let/in blocks. They will mostly be fine, but sometimes a function in a let/in block will be omitted.

## EXAMPLES

### Imports
Imported modules are tagged, and their role is "imported", not "def". Types, functions, etc which are exposed via imported module have their role as "exposed".

Exposed items are marked as being in the scope of their own module, not the module that's doing the importing.

"input.elm"

```
module SomeMod exposing (..)
import MyMod exposing

  ( map

  , Maybe

  , Result(..)

  , MyList(Empty)

  )
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+r --fields=+r input.elm"

```
SomeMod input.elm       /^module SomeMod exposing (..)$/;"      m       roles:def
MyMod   input.elm       /^import MyMod exposing$/;"     m       roles:imported
map     input.elm       /^  ( map$/;"   f       module:MyMod    roles:exposed
Maybe   input.elm       /^  , Maybe$/;" t       module:MyMod    roles:exposed
Result  input.elm       /^  , Result(..)$/;"    t       module:MyMod    roles:exposed
MyList  input.elm       /^  , MyList(Empty)$/;" t       module:MyMod    roles:exposed
Empty   input.elm       /^  , MyList(Empty)$/;" c       type:MyMod.MyList       roles:exposed
```

### Namespaces
Namespaces are tagged and their role is "def".

"input.elm"

```
module AMod exposing (..)
import MyImport as NSpace exposing (impFunc)
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+r --fields=+r input.elm"

```
AMod    input.elm       /^module AMod exposing (..)$/;" m       roles:def
NSpace  input.elm       /^import MyImport as NSpace exposing (impFunc)$/;"      n       module:AMod     roles:def       moduleName:MyImport
MyImport        input.elm       /^import MyImport as NSpace exposing (impFunc)$/;"      m       roles:imported
impFunc input.elm       /^import MyImport as NSpace exposing (impFunc)$/;"      f       module:MyImport roles:exposed
```

### Type names
Constructors top level functions will have type names.

"input.elm"

```
funcA : Int -> Int
funcA a = a + 1
type B

    = B1Cons

      { x : Float

      , y : Float

      }

    | B2Cons String Integer

    | B3Cons
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+r --fields=+r input.elm"

```
funcA   input.elm       /^funcA a = a + 1$/;"   f       typeref:typename:Int -> Int     roles:def
B       input.elm       /^type B$/;"    t       roles:def
B1Cons  input.elm       /^    = B1Cons$/;"      c       type:B  typeref:typename:{ x : Float , y : Float } -> B roles:def
B2Cons  input.elm       /^    | B2Cons String Integer$/;"       c       type:B  typeref:typename:String -> Integer -> B roles:def
B3Cons  input.elm       /^    | B3Cons$/;"      c       type:B  typeref:typename:B      roles:def
```

### Function parameter lists
Function parameter lists can be extracted into the tags file signature field. They are not really function signatures, but it's the closest concept available in ctags. Use "--fields=+S".

```
funcA a1 a2 =

    a1 + a2
```

"output.tags" with "--sort=no --extras=+r --fields=+rS"

```
funcA       input.elm       /^funcA a1 a2 =$/;"     f       signature:a1 a2 roles:def
```

## KNOWN LIMITATIONS
The ctags signature field is used for function parameter lists, even though it's not an idea field. See above.

Elm requires all statements at the same logical level to have the same indentation. If there is additional indentation that line is part of the previous one. Therefore without over-complicating the PEG parser we have the following limitations...

Sometimes functions in let/in blocks will be omitted.

Functions in let/in blocks will be marked as being in the scope of their outer function, regardless of how deeply nested the let/in block is.

Functions in let/in blocks won't have type names.

## SEE ALSO
ctags(1), ctags-client-tools(7)


ctags-lang-emacslisp

title: ctags-lang-emacslisp(7)

text:
# ctags-lang-emacslisp(7)

## NAME
ctags-lang-emacslisp - Random notes about tagging EmacsLisp source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+EmacsLisp ...
ctags ... --language-force=EmacsLisp ...
ctags ... --map-Lisp=+.el ...
```

## DESCRIPTION
This man page gathers random notes about tagging EmacsLisp source code.

## VERSIONS

### Change since "0.0"
•

Add definer field.

## SEE ALSO
ctags(1)


ctags-lang-fortran

title: ctags-lang-fortran(7)

text:
# ctags-lang-fortran(7)

## NAME
ctags-lang-fortran - Random notes about tagging Fortran source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Fortran ...
ctags ... --language-force=Fortran ...
ctags ... --map-Fortran=+.f ...
```

## DESCRIPTION
This man page gathers random notes about tagging FORTRAN source code.

## VERSIONS

### Change since "0.0"
•

New extra linkName.

## SEE ALSO
ctags(1)


ctags-lang-gdscript

title: ctags-lang-gdscript(7)

text:
# ctags-lang-gdscript(7)

## NAME
ctags-lang-gdscript - Random notes about tagging GDScript source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+GDScript ...
ctags ... --language-force=GDScript ...
ctags ... --map-GDScript=+.gd ...
```

## DESCRIPTION
This man page gathers random notes about tagging GDScript source code with Universal Ctags.

## STORING ANNOTATIONS
Like the Python parser storing decorations to decorations field, the GDScript parser stores annotations starting from @ to the language specific field, annotations. Though the field is enabled explicitly in following examples, the field is enabled by default.

"input.gd"

```
@export
var s = "Hello"
@master
func f(msg):

        print(msg)
```

"output.tags" with "--options=NONE --sort=no --fields-GDScript=+{annotations} -o - input.gd"

```
s       input.gd        /^var s = "Hello"$/;"   v       annotations:export
f       input.gd        /^func f(msg):$/;"      m       annotations:master
```

## EXTRACTING FUNC
A language object defined with func keyword is tagged with method kind. Like annotations, the parser stores keywords modifying func like static to the annotations field.

"input.gd"

```
func f(x):

        return x
static func f_s(x):

        reutrn x
remote func f_r(x):

        return x
```

"output.tags" with "--options=NONE --sort=no --fields=+K --fields-GDScript=+{annotations} -o - input.gd"

```
f       input.gd        /^func f(x):$/;"        method
f_s     input.gd        /^static func f_s(x):$/;"       method  annotations:static
f_r     input.gd        /^remote func f_r(x):$/;"       method  annotations:remote
```

## TAGGING IMPLICITLY DEFINED CLASSES
"A file is a class!" in GDScript. A class is implicitly defined. Functions, variables, constants, and signals are parts of the class though the class is unnamed by default.

If the language specific extra, implicitClass, is enabled, the parser makes a anonymous tag for the class. The parser fills the scope fields of the tags for all language objects defined in the file with the anonymous tag.

Let's see an example demonstrating the effect of the extra.

Turning off the extra:

"input.gd"

```
func f(x):

        return x
```

"output.tags" with "--options=NONE --fields=+KZ --extras-GDScript=-{implicitClass} -o - input.gd"

```
f       input.gd        /^func f(x):$/;"        method
```

Turning on the extra:

"input.gd"

```
func g(x):

        return x
```

"output.tags" with "--options=NONE --fields=+KZ --extras-GDScript=+{implicitClass} -o - input.gd"

```
anon_class_84011bee0100 input.gd        /^func g(x):$/;"        class
g       input.gd        /^func g(x):$/;"        method  scope:class:anon_class_84011bee0100
```

## TAGGING THE NAME SPECIFIED WITH CLASS_NAME
class_name is a keyword for giving a name to the implicitly defined class. If implicitClass is turned off, the parser just extract the name coming after the keyword with class kind. If implicitClass is turned on, the parser converts the anonymous tag to a non-anonymous tag with the specified name. When converting, the parser also updates scope fields of the other tags in the file.

Turning off the extra:

"input.gd"

```
class_name c
func f(x):

        return x
```

"output.tags" with "--options=NONE --fields=+KZ --extras-GDScript=-{implicitClass} -o - input.gd"

```
c       input.gd        /^class_name c$/;"      class
f       input.gd        /^func f(x):$/;"        method
```

Turning on the extra:

"input.gd"

```
class_name C
func g(x):

        return x
```

"output.tags" with "--options=NONE --fields=+KZ --extras-GDScript=+{implicitClass} -o - input.gd"

```
C       input.gd        /^class_name C$/;"      class
g       input.gd        /^func g(x):$/;"        method  scope:class:C
```

## FILLING INHERITS FIELD
extends keyword specifies the super class for the implicitly defined class. If implicitClass extra is turned on, the parser fills inherits field of the tag for the implicitly defined class with the name of super class.

"input.gd"

```
extends B
class_name C
```

"output.tags" with "--options=NONE --fields=+Ki --extras-GDScript=+{implicitClass} -o - input.gd"

```
C       input.gd        /^class_name C$/;"      class   inherits:B
```

When --extras=+r is given, the parser extracts the class specified with the extends keyword as a reference tag of class kind with extended role.

"input.gd"

```
extends B
```

"output.tags" with "--options=NONE --fields=+rEK --extras=+r -o - input.gd"

```
B       input.gd        /^extends B$/;" class   roles:extended  extras:reference
```

## SEE ALSO
ctags(1)


title: ctags-lang-i18nrubygem(7)

text:
# ctags-lang-i18nrubygem(7)

## NAME
ctags-lang-i18nrubgem - Random notes about tagging input for I18n Ruby Gem with Universal Ctags

## SYNOPSIS

```
ctags ... --extras=+s --languages=+I18nRubyGem ...
ctags ... --extras=+s --language-force=I18nRubyGem ...
ctags ... --extras=+s --map-I18nRubyGem=+.yaml ...
ctags ... --extras=+s --map-I18nRubyGem=+.yml ...
```

## DESCRIPTION
This man page gathers random notes about tagging input for I18n Ruby Gem [RUBYI18N]. I18nRubyGem is a subparser running on Yaml parser. If a top-level scalar token of a given Yaml source input is a local name [ISOCODES], I18nRubyGem activates itself. If not, I18nRubyGem does nothing.

"input.yaml"

```
---
ja:

  msg:

    error: エラー

    function: 関数
```

"output.tags" with "--options=NONE -o - --fields=+E input.yaml"

```
error   input.yaml      /^    error: エラー$/;"    k       keyInMiddle:ja.msg      extras:subparser
function        input.yaml      /^    function: 関数$/;"  k       keyInMiddle:ja.msg      extras:subparser
ja.msg.error    input.yaml      /^    error: エラー$/;"    k       keyInMiddle:ja.msg      extras:subparser,localeful
ja.msg.function input.yaml      /^    function: 関数$/;"  k       keyInMiddle:ja.msg      extras:subparser,localeful
msg.error       input.yaml      /^    error: エラー$/;"    k       locale:ja       extras:subparser,localeless
msg.function    input.yaml      /^    function: 関数$/;"  k       locale:ja       extras:subparser,localeless
```

With the options, the parser emits three tag entries for a key: "error", "js.msg.error", and "msg.error" for the key "error", The parser emits "error" at the first line always.

To emit "ja.msg.error", a localeful extra tag, at the fifth line always. If you specify --extra=+q or --extra=+{qualified}, ctags emits the same tag twice: a localeful tag, and a qualified tag. You can suppress the localeful extra tags., specify --extras-I18nRubyGem=-{localeful}.

To emit "msg.error", a localeless extra tag, at the fifth line always. The parser creates a localeless extra tag by truncating the first component (e.g. "ja.") from the associated full qualified extra tag (e.g. "ja.msg.error"). localeless extra is enabled by default. If you don't need localeless extra tags, specify --extras-I18nRubyGem=-{localeless}.

The parser doesn't make tag entries for top-level and mid-level components like ja and msg by default. If you need them, specify --kinds-I18nRubyGem=+{locale} and/or --kinds-I18nRubyGem=+{keyInMiddle}.

## KNOWN BUGS
The mechanism activating I18nRubyGem subparser doesn't work well for YAML source input containing multiple documents.

## SEE ALSO
ctags(1)

## REFERENCES
[RUBYI18N]

Ruby I18n, <https://github.com/ruby-i18n/i18n>

[ISOCODES]

iso-codes, <https://salsa.debian.org/iso-codes-team/iso-codes> Expected feature: yaml


ctags-lang-iPythonCell

title: ctags-lang-iPythonCell(7)

text:
# ctags-lang-iPythonCell(7)

## NAME
ctags-lang-iPythonCell - The man page of the iPythonCell parser for Universal Ctags

## SYNOPSIS

```
ctags ... --extras=+{subparser} --languages=+iPythonCell,Python \

[--extras-IPythonCell=+{doubleSharps}] \
[--regex-IPythonCell=/<PATTERN>/\n/c/] ...
```

## DESCRIPTION
iPythonCell parser is a subparser stacked on top of the Python parser. It works when:

- the Python parser is enabled,

- the subparser extra is enabled, and

- the iPythonCell parser itself is enabled.

The iPythonCell parser extracts cells explained as in vim-ipython-cell ( <https://github.com/hanschen/vim-ipython-cell/blob/master/README.md> ).

## KIND(S)
The iPythonCell parser defines only a cell kind.

## EXTRA(S)
Tagging cells staring with ##... is disabled by default because the pattern is too generic; with that pattern unwanted tags can be extracted.

Enable doubleSharps language specific extra for tagging cells staring with ##....

## CUSTOMIZING
If your favorite cell pattern is not supported in the parser, you can define the pattern in your .ctagd.d/your.ctags or command lines. Here is an example how to support "# CTAGS: ...":

"input.py"

```
x=1
# CTAGS: DEFINE F
def F():

        # CTAGS: DO NOTING

        pass
```

"output.tags" with "--options=NONE --sort=no --extras=+{subparser} --regex-IPythonCell=/[ t]*# CTAGS:[ ]?(.*)$/1/c/ -o - input.py"

```
x    input.py        /^x=1$/;"       v
DEFINE F     input.py        /^# CTAGS: DEFINE F$/;" c
F    input.py        /^def F():$/;"  f
DO NOTING    input.py        /^      # CTAGS: DO NOTING$/;"  c
```

You can put "--regex-IPythonCell=/[ \t]*# CTAGS:[ ]?(.*)$/\1/c/" in your.ctags to avoid specifying the pattern repeatedly.

## SEE ALSO
ctags(1), ctags-client-tools(7), ctags-lang-python(7)


ctags-lang-inko

title: ctags-lang-inko(7)

text:
# ctags-lang-inko(7)

## NAME
ctags-lang-inko -

## SYNOPSIS

```
ctags ... --languages=+Inko ...
ctags ... --language-force=Inko ...
ctags ... --map-Inko=+.inko ...
```

## DESCRIPTION
This man page describes the Inko parser for Universal Ctags.

The input file is expected to be valid Inko source code, otherwise the output of ctags is undefined.

Tags are generated for objects, traits, methods, attributes, and constants. String literals are ignored.

## SEE ALSO
ctags(1), ctags-client-tools(7)


ctags-lang-javascript

title: ctags-lang-javascript(7)

text:
# ctags-lang-javascript(7)

## NAME
ctags-lang-javascript - Random notes about tagging JavaScript source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+JavaScript ...
ctags ... --language-force=JavaScript ...
ctags ... --map-JavaScript=+.js ...
```

## DESCRIPTION
This man page gathers random notes about tagging JavaScript source code.

## CLASSES
ES6 introduced the class keyword, but there is still the original method of defining a function and attaching a prototype. ctags follows the convention that function names that start with a capital letter are class constructors.

### Change since "0.0"
•

New role foreigndecl for function kind

## SEE ALSO
ctags(1), ctags-client-tools(7)


ctags-lang-julia

title: ctags-lang-julia(7)

text:
# ctags-lang-julia(7)

## NAME
ctags-lang-julia - Random notes about tagging Julia source code with Universal-ctags

## SYNOPSIS

```
ctags ... --languages=+Julia ...
ctags ... --language-force=Julia ...
ctags ... --map-Julia=+.jl ...
```

## DESCRIPTION
This man page gathers random notes about tagging Julia source code.

## TAGGING IMPORT AND USING EXPRESSIONS

### Summary
using X

name

kind

role

other noticeable fields

X

module

used

N/A

using X: a, b

name

kind

role

other noticeable fields

X

module

namespace

N/A

a, b

unknown

used

scope:module:X

import X

name

kind

role

other noticeable fields

X

module

imported

N/A

import X.a, Y.b

name

kind

role

other noticeable fields

X, Y

module

namespace

N/A

a

unknown

imported

scope:module:X

b

unknown

imported

scope:module:Y

import X: a, b

name

kind

role

other noticeable fields

X

module

namespace

N/A

a,b

unknown

imported

scope:module:X

### Examples
"input.jl"

```
using X0
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK input.jl"

```
X0      input.jl        /^using X0$/;"  kind:module     roles:used
```

--extras=+r (or --extras=+{reference}) option is needed for this tag, since it's a reference tag. This is because module X is not defined here. It is defined in another file. Enable roles: field with --fields=+r is for recording that the module is "used", i.e., loaded by using.

"input.jl"

```
import X1.a, X2.b, X3
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzKZ input.jl"

```
X1      input.jl        /^import X1.a, X2.b, X3$/;"     kind:module     roles:namespace
X2      input.jl        /^import X1.a, X2.b, X3$/;"     kind:module     roles:namespace
X3      input.jl        /^import X1.a, X2.b, X3$/;"     kind:module     roles:imported
a       input.jl        /^import X1.a, X2.b, X3$/;"     kind:unknown    scope:module:X1 roles:imported
b       input.jl        /^import X1.a, X2.b, X3$/;"     kind:unknown    scope:module:X2 roles:imported
```

Why X1 and X2 have role "namespace", while X3 have role "imported"? It's because the symbol a in module X1, and b in module X2 are brought to the current scope, but X1 and X2 themselves are not. We use "namespace" role for such modules.

X3 is different. The symbol X3, together with all exported symbols in X3, is brought to current scope. For such modules, we use "imported" or "used" role depending whether they are loaded by import or using.

Also, notice that a and b have the "unknown" kind. This is because we cannot know whether it's a function, constant, or macro, etc.

## SEE ALSO
ctags(1), ctags-client-tools(7)


ctags-lang-kconfig

title: ctags-lang-kconfig(7)

text:
# ctags-lang-kconfig(7)

## NAME
ctags-lang-kconfig - Random notes about tagging Kconfig source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Kconfig ...
ctags ... --language-force=Kconfig ...
ctags ... --map-Kconfig=+(Kconfig*) ...
```

## DESCRIPTION
This man page gathers random notes about tagging Kconfig scripts.

## VERSIONS

### Change since "0.0"
•

New kind variable

## SEE ALSO
ctags(1), Kconfig Language <https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html>

( <https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html> ), Kconfig macro language <https://www.kernel.org/doc/html/latest/kbuild/kconfig-macro-language.html>

( <https://www.kernel.org/doc/html/latest/kbuild/kconfig-macro-language.html> ),


ctags-lang-ldscript

title: ctags-lang-ldscript(7)

text:
# ctags-lang-ldscript(7)

## NAME
ctags-lang-ldscript - Random notes about tagging LdScript source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+LdScript ...
ctags ... --language-force=LdScript ...
ctags ... --map-LdScript=+.lds ...
ctags ... --map-LdScript=+.lds.S ...
```

## DESCRIPTION
This man page gathers random notes about tagging LdScript source code.

## VERSIONS

### Change since "0.0"

- New role destination for inputSection kind

- New role aliased for symbol kind

## SEE ALSO
ctags(1), ctags-lang-asm(7), ctags-lang-c(7), ctags-lang-c++(7), ctags-lang-cuda(7)


ctags-lang-lex

title: ctags-lang-lex(7)

text:
# ctags-lang-lex(7)

## NAME
ctags-lang-lex - Random notes about tagging Lex source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+LEX ...
ctags ... --language-force=LEX ...
ctags ... --map-Lex=+.l ...
```

## DESCRIPTION
This man page gathers random notes about tagging LEX source code.

## VERSIONS

### Change since "0.0"
•

New role grouping for cond kind

## SEE ALSO
ctags(1)


ctags-lang-lisp

title: ctags-lang-lisp(7)

text:
# ctags-lang-lisp(7)

## NAME
ctags-lang-lisp - Random notes about tagging Lisp source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Lisp ...
ctags ... --language-force=Lisp ...
ctags ... --map-Lisp=+.cl ...
ctags ... --map-Lisp=+.clisp ...
ctags ... --map-Lisp=+.l ...
ctags ... --map-Lisp=+.lisp ...
ctags ... --map-Lisp=+.lsp ...
```

## DESCRIPTION
This man page gathers random notes about tagging Lisp source code.

## VERSIONS

### Change since "0.0"
•

Add kinds:

- class,

- generic,

- method,

- parameter,

- struct, and

- type.

•

Add definer field.

## SEE ALSO
ctags(1)


ctags-lang-make

title: ctags-lang-make(7)

text:
# ctags-lang-make(7)

## NAME
ctags-lang-make - Random notes about tagging Make source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Make ...
ctags ... --language-force=Make ...
ctags ... --map-Make=+([Mm]akefile) --map-Make=+(GNUmakefile) ...
ctags ... --map-Make=+.mak --map-Make=+.mk ...
```

## DESCRIPTION
This parser extracts macro and target definitions. It also extracts included files as references.

### Examples
"input.mak"

```
-include base.mak
SRC = hello.c
all: hello
hello: hello.o
hello.o: hello.c
$(CC) -c $(CFLAGS) $(CPPFLAGS) $<
```

"output.tags" with "--options=NONE --extras=+r --fields=+KlrE -o - input.mak"

```
SRC  input.mak       /^SRC = hello.c$/;"     macro   language:Make   roles:def
all  input.mak       /^all: hello$/;"        target  language:Make   roles:def
base.mak     input.mak       /^-include base.mak$/;" makefile        language:Make   roles:optional  extras:reference
hello        input.mak       /^hello: hello.o$/;"    target  language:Make   roles:def
hello.o      input.mak       /^hello.o: hello.c$/;"  target  language:Make   roles:def
```

## EXTRACTING CPP MACRO DEFINTIONS DEFINED WITH -DFOO
With -D option in a C compiler like gcc, a programmer can define a macro outside C source files. The options appears on a Makefile frequently. For an example:

```
CPPFLAGS = -DDEBUG
```

The Make parser has heuristics [DINMAKE] for extracting the macros defined with the option. With enabling CppDef extra, you can turn on the heuristics.

### Examples
"input.mak"

```
-include base.mak
CFLAGS = -g -O2
CPPFLAGS = -DOUTPUT=stdout
SRC = hello.c
all: hello
hello: hello.o
hello.o: hello.c
$(CC) -c $(CFLAGS) $(CPPFLAGS) $<
```

"output.tags" with "--options=NONE --extras-Make=+{CppDef} --fields=+KlE -o - input.mak"

```
CFLAGS       input.mak       /^CFLAGS = -g -O2$/;"   macro   language:Make
CPPFLAGS     input.mak       /^CPPFLAGS = -DOUTPUT=stdout$/;"        macro   language:Make
OUTPUT       input.mak       /^CPPFLAGS = -DOUTPUT=stdout$/;"        macro   language:CPreProcessor  extras:CppDef
SRC  input.mak       /^SRC = hello.c$/;"     macro   language:Make
all  input.mak       /^all: hello$/;"        target  language:Make
hello        input.mak       /^hello: hello.o$/;"    target  language:Make
hello.o      input.mak       /^hello.o: hello.c$/;"  target  language:Make
```

## VERSIONS

### Change since "0.0"
•

New extra CppDef [DINMAKE]

## SEE ALSO
ctags(1)

[DINMAKE]

CONFIG_X86_X32_ABI is not visible (defined in Makefile, not C or Kconfig) <https://github.com/bootlin/elixir/issues/221>

( <https://github.com/bootlin/elixir/issues/221> )


ctags-lang-markdown

title: ctags-lang-markdown(7)

text:
# ctags-lang-markdown(7)

## NAME
ctags-lang-markdown - Random notes about tagging Markdown source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Markdown ...
ctags ... --language-force=Markdown ...
ctags ... --map-Markdown=+.md ...
```

## DESCRIPTION
This man page gathers random notes about tagging Markdown documents [XSYNTAX].

## VERSIONS

### Change since "0.0"
•

New kind hashtag [HASHTAG]

## SEE ALSO
ctags(1)

[XSYNTAX]

Extend Syntax <https://www.markdownguide.org/extended-syntax/>

( <https://www.markdownguide.org/extended-syntax/> ) in Markdown Guide

[HASHTAG]

Hashtags in Markdown notes for VSCode <https://github.com/vanadium23/markdown-hashtags#hashtags-in-markdown-notes-for-vscode>

( <https://github.com/vanadium23/markdown-hashtags#hashtags-in-markdown-notes-for-vscode> )


ctags-lang-meson

title: ctags-lang-meson(7)

text:
# ctags-lang-meson(7)

## NAME
ctags-lang-meson - Random notes about tagging Meson build scripts with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Meson ...
ctags ... --language-force=Meson ...
ctags ... --map-Meson=+(meson.build) ...
```

## DESCRIPTION
This man page gathers random notes about tagging Meson build scripts.

### Change since "0.0"
•

New kinds cfgdata and cfgvar

## SEE ALSO
ctags(1), ctags-client-tools(7)


ctags-lang-powershell

title: ctags-lang-powershell(7)

text:
# ctags-lang-powershell(7)

## NAME
ctags-lang-powershell - Random notes about tagging PowerShell source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+PowerShell ...
ctags ... --language-force=PowerShell ...
ctags ... --map-powershell=+.ps1 ...
ctags ... --map-powershell=+.psm1 ...
```

## DESCRIPTION
This man page gathers random notes about tagging PowerShell source code.

## VERSIONS

### Change since "0.0"
•

New kind enumlabel

## SEE ALSO
ctags(1)


ctags-lang-python

title: ctags-lang-python(7)

text:
# ctags-lang-python(7)

## NAME
ctags-lang-python - Random notes about tagging python source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Python ...
ctags ... --language-force=Python ...
ctags ... --map-Python=+.py ...
```

## DESCRIPTION
This man page gathers random notes about tagging python source code.

## TAGGING IMPORT STATEMENTS

### Summary
import X

name

kind

role

other noticeable fields

X

module

imported

N/A

import X as Y

name

kind

role

other noticeable fields

X

module

indirectlyImported

N/A

Y

namespace

definition

nameref:module:X

from X import *

name

kind

role

other noticeable fields

X

module

namespace

N/A

from X import Y

name

kind

role

other noticeable fields

X

module

namespace

N/A

Y

unknown

imported

scope:module:X

from X import Y as Z

name

kind

role

other noticeable fields

X

module

namespace

N/A

Y

unknown

indirectlyImported

scope:module:X

Z

unknown

definition

nameref:unknown:Y

### Examples
"input.py"

```
import X0
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK input.py"

```
X0      input.py        /^import X0$/;" kind:module     roles:imported
```

A tag for an imported module has module kind with imported role. The module is not defined here; it is defined in another file. So the tag for the imported module is a reference tag; specify --extras=+r (or --extras=+{reference}) option for tagging it. "roles:" field enabled with --fields=+r is for recording the module is "imported" to the tag file.

"input.py"

```
import X1 as Y1
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK --fields-Python=+{nameref} input.py"

```
X1      input.py        /^import X1 as Y1$/;"   kind:module     roles:indirectlyImported
Y1      input.py        /^import X1 as Y1$/;"   kind:namespace  roles:def       nameref:module:X1
```

"Y1" introduces a new name and is defined here. So "Y1" is tagged as a definition tag. "X1" is imported in a way that its name cannot be used in this source file. For letting client tools know that the name cannot be used, indirectlyImported role is assigned for "X1". "Y1" is the name for accessing objects defined in the module imported via "X1". For recording this relationship, nameref: field is attached to the tag of "Y1". Instead of module kind, namespace kind is assigned to "Y1" because "Y1" itself isn't a module.

"input.py"

```
from X2 import *
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzK input.py"

```
X2      input.py        /^from X2 import *$/;"  kind:module     roles:namespace
```

The module is not defined here; it is defined in another file. So the tag for the imported module is a reference tag. Unlike "X0" in "import X0", "X2" may not be used because the names defined in "X2" can be used in this source file. To represent the difference namespace role is attached to "X2" instead of imported.

"input.py"

```
from X3 import Y3
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzKZ input.py"

```
X3      input.py        /^from X3 import Y3$/;" kind:module     roles:namespace
Y3      input.py        /^from X3 import Y3$/;" kind:unknown    scope:module:X3 roles:imported
```

"Y3" is a name for a language object defined in "X3" module. "scope:module:X3" attached to "Y3" represents this relation between "Y3" and "X3". ctags assigns unknown kind to "Y3" because ctags cannot know whether "Y3" is a class, a variable, or a function from the input file.

"input.py"

```
from X4 import Y4 as Z4
```

"output.tags" with "--options=NONE -o - --extras=+r --fields=+rzKZ input.py"

```
X4      input.py        /^from X4 import Y4 as Z4$/;"   kind:module     roles:namespace
Y4      input.py        /^from X4 import Y4 as Z4$/;"   kind:unknown    scope:module:X4 roles:indirectlyImported
Z4      input.py        /^from X4 import Y4 as Z4$/;"   kind:unknown    roles:def       nameref:unknown:Y4
```

"Y4" is similar to "Y3" of "from X3 import Y3" but the name cannot be used here. indirectlyImported role assigned to "Y4" representing this. "Z4" is the name for accessing the language object named in "Y4" in "X4" module. "nameref:unknown:Y4" attached to "Z4" and "scope:module:X4" attached to "Y4" represent the relations.

## LAMBDA EXPRESSION AND TYPE HINT

### Summary
id = lambda var0: var0

name

kind

role

other noticeable fields

id

function

definition

signature:(var0)

id_t: Callable[[int], int] = lambda var1: var1

name

kind

role

other noticeable fields

id_t

variable

definition

typeref:typename:Callable[[int], int] nameref:function:anonFuncN

anonFuncN

function

definition

signature:(var1)

### Examples
"input.py"

```
from typing import Callable
id = lambda var0: var0
id_t: Callable[[int], int] = lambda var1: var1
```

"output.tags" with "--options=NONE -o - --sort=no --fields=+KS --fields-Python=+{nameref} --extras=+{anonymous} input.py"

```
id      input.py        /^id = lambda var0: var0$/;"    function        signature:(var0)
id_t    input.py        /^id_t: Callable[[int], int] = lambda var1: var1$/;"\

        variable        typeref:typename:Callable[[int], int]   nameref:function:anonFunc84011d2c0101
anonFunc84011d2c0101    input.py        /^id_t: Callable[[int], int] = lambda var1: var1$/;"\

        function        signature:(var1)
```

If a variable ("id") with no type hint is initialized with a lambda expression, ctags assigns function kind for the tag of "id".

If a variable ("id_t") with a type hint is initialized with a lambda expression, ctags assigns variable kind for the tag of "id_t" with typeref: and nameref: fields. ctags fills typeref: field with the value of the type hint. The way of filling nameref: is a bit complicated.

For the lambda expression used in initializing the type-hint'ed variable, ctags creates anonymous extra tag ("anonFunc84011d2c0101"). ctags fills the nameref: field of "id_t" with the name of anonymous extra tag: "nameref:function:anonFunc84011d2c0101".

You may think why ctags does so complicated, and why ctags doesn't emit following tags output for the input:

```
id      input.py        /^id = \\$/;"   function        signature:(var0)
id_t    input.py        /^id_t: \\$/;"  function        typeref:typename:Callable[[int], int]   signature:(var1)
```

There is a reason. The other languages of ctags obey the following rule: ctags fills typeref: field for a tag of a callable object (like function) with the type of its return value. If we consider "id_t" is a function, its typeref: field should have "typename:int". However, for filling typeref: with "typename:int", ctags has to analyze "Callable[[int], int]" deeper. We don't want to do so.

## VERSIONS

### Change since "0.0"

- New role entryPoint for module kind PythonEntryPoints parser emits tag entries having this role.

- New role entryPoint for function kind PythonEntryPoints parser emits tag entries having this role.

## SEE ALSO
ctags(1), ctags-client-tools(7), ctags-lang-iPythonCell(7)


ctags-lang-r

title: ctags-lang-r(7)

text:
# ctags-lang-r(7)

## NAME
ctags-lang-r - Random notes about tagging R source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+R ...
ctags ... --language-force=R ...
ctags ... --map-R=+.r ...
```

## DESCRIPTION
This man page gathers random notes about tagging R source code with Universal Ctags.

## KINDS
If a variable gets a value returned from a well-known constructor and the variable appears for the first time in the current input file, the R parser makes a tag for the variable and attaches a kind associated with the constructor to the tag regardless of whether the variable appears in the top-level context or a function.

Well-known constructor and kind mapping

Constructor

kind

function()

function

c()

vector

list()

list

data.frame()

dataframe

If a variable doesn't get a value returned from one of well-known constructors, the R parser attaches globalVar or functionVar kind to the tag for the variable depending on the context.

Here is an example demonstrating the usage of the kinds:

"input.r"

```
G <- 1
v <- c(1, 2)
l <- list(3, 4)
d <- data.frame(n = v)
f <- function(a) {

        g <- function (b) a + b

        w <- c(1, 2)

        m <- list (3, 4)

        e <- data.frame(n = w)

        L <- 2
}
```

"output.tags" with "--options=NONE --sort=no --fields=+KZ -o - input.r"

```
G       input.r /^G <- 1$/;"    globalVar
v       input.r /^v <- c(1, 2)$/;"      vector
l       input.r /^l <- list(3, 4)$/;"   list
d       input.r /^d <- data.frame(n = v)$/;"    dataframe
n       input.r /^d <- data.frame(n = v)$/;"    nameattr        scope:dataframe:d
f       input.r /^f <- function(a) {$/;"        function
g       input.r /^      g <- function (b) a + b$/;"     function        scope:function:f
w       input.r /^      w <- c(1, 2)$/;"        vector  scope:function:f
m       input.r /^      m <- list (3, 4)$/;"    list    scope:function:f
e       input.r /^      e <- data.frame(n = w)$/;"      dataframe       scope:function:f
n       input.r /^      e <- data.frame(n = w)$/;"      nameattr        scope:dataframe:f.e
L       input.r /^      L <- 2$/;"      functionVar     scope:function:f
```

## SEE ALSO
ctags(1)


ctags-lang-rmarkdown

title: ctags-lang-rmarkdown(7)

text:
# ctags-lang-rmarkdown(7)

## NAME
ctags-lang-rmarkdown - Random notes about tagging R Markdown source code with Universal Ctags

## SYNOPSIS

```
ctags ...--extras=+{subparser}{guest} --languages=+RMarkdown ...
ctags ...--extras=+{subparser}{guest} --language-force=RMarkdown ...
ctags ...--extras=+{subparser}{guest} --map-RMarkdown=+.rmd ...
```

## DESCRIPTION
RMarkdown parser is an exclusive subparser stacked on top of the Markdown parser. It works when:

- the Markdown parser is enabled,

- the subparser extra is enabled, and

- the RMarkdown parser itself is enabled.

The RMarkdown parser extends the way of detecting codeblocks from the Markdown parser. This extension is for running guest parsers on code chunks.

The Markdown parser expects the following syntax represents codeblocks:

````
```language-name

        ...
```
````

For an example

````
```r

        ...
```
````

The RMarkdown parser accepts the following syntax for code chunks:

````
```{language-name chunk-label, ...}

        ...
```
````

For an example

````
```{r precalc fig.height=4}

        ...
```
````

Give --extras=+{guest} for enabling guest to command line if you want to run proper parsers on lines inside code chunks.

The parser extracts chunk labels coming after language-name as chunklabel kind objects. In the example, the RMarkdown parser extracts precalc as a chunklabel kind object. The chunklabel kind is enabled by default.

## EXAMPLES
"input.rmd"

````
# Section 1
```{r myblock}

        zero_fun <- function () {

                return 0

        }
```
# Section 2
````

"output.tags" with "--options=NONE --extras=+{guest} --fields=+KZln -o - input.rmd"

````
Section 1       input.rmd       /^# Section 1$/;"       chapter line:1  language:Markdown
Section 2       input.rmd       /^# Section 2$/;"       chapter line:9  language:Markdown
myblock input.rmd       /^```{r myblock}$/;"    chunklabel      line:3  language:RMarkdown
zero_fun        input.rmd       /^      zero_fun <- function () {$/;"   function        line:4  language:R
````

## SEE ALSO
ctags(1), ctags-client-tools(7), ctags-lang-r(7), R Markdown: The Definitive Guide <https://bookdown.org/yihui/rmarkdown/>


ctags-lang-scheme

title: ctags-lang-scheme(7)

text:
# ctags-lang-scheme(7)

## NAME
ctags-lang-scheme - Random notes about tagging Scheme source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+Scheme ...
ctags ... --language-force=Scheme ...
ctags ... --map-Scheme=+.SCM ...
ctags ... --map-Scheme=+.SM ...
ctags ... --map-Scheme=+.sch ...
ctags ... --map-Scheme=+.scheme ...
ctags ... --map-Scheme=+.scm ...
ctags ... --map-Scheme=+.sm ...
ctags ... --map-Scheme=+.rkt ...
```

## DESCRIPTION
This man page gathers random notes about tagging Scheme source code.

## VERSIONS

### Change since "0.0"

- Add unknown kind.

- Add definer field.

## SEE ALSO
ctags(1)


ctags-lang-scss

title: ctags-lang-scss(7)

text:
# ctags-lang-scss(7)

## NAME
ctags-lang-scss - Random notes about tagging SCSS source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+SCSS ...
ctags ... --language-force=SCSS ...
ctags ... --map-Scss=+.scss ...
```

## DESCRIPTION
This man page gathers random notes about tagging SCSS input.

## VERSIONS

### Change since "0.0"

- New kind module and new role used of the module kind

- New kind namespace

- New field module

## SEE ALSO
ctags(1)


ctags-lang-sql

title: ctags-lang-sql(7)

text:
# ctags-lang-sql(7)

## NAME
ctags-lang-sql - The man page of the SQL parser for Universal Ctags

## SYNOPSIS

```
ctags ... [--extras={guest}] --languages=+SQL ...
```

## DESCRIPTION
The SQL parser supports various SQL dialects. PostgreSQL is one of them.

PostgreSQL allows user-defined functions to be written in other languages (procedural languages) besides SQL and C [PL].

The SQL parser makes tags for language objects in the user-defined functions written in the procedural languages if the guest extra is enabled.

The SQL parser looks for a token coming after LANGUAGE keyword in the source code to choose a proper guest parser.

```
... LANGUAGE plpythonu AS '... user-defined function ' ...
... AS $$ user-defined function $$ LANGUAGE plv8 ...
```

In the above examples, plpythonu and plv8 are the names of procedural languages. The SQL parser trims pl at the start and u at the end of the name before finding a ctags parser. For plpythonu and plv8, the SQL parser extracts python and v8 as the candidates of guest parsers.

For plpythonu, ctags can run its Python parser. ctags doesn't have a parser named v8. However, the JavaScript parser in ctags has v8 as an alias. So ctags can run the JavaScript parser as the guest parser for plv8.

## EXAMPLES
tagging code including a user-defined function in a string literal [GH3006]:

"input.sql"

```
CREATE OR REPLACE FUNCTION fun1() RETURNS VARCHAR AS '
DECLARE

        test1_var1 VARCHAR(64) := $$ABC$$;

        test1_var2 VARCHAR(64) := $xyz$XYZ$xyz$;

        test1_var3     INTEGER := 1;
BEGIN

        RETURN  TO_CHAR(test_var3, ''000'') || test1_var1 || test1_var2;
END;
' LANGUAGE plpgsql;
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.sql"

```
fun1    input.sql       /^CREATE OR REPLACE FUNCTION fun1() RETURNS VARCHAR AS '$/;"    f       typeref:typename:VARCHAR
test1_var1      input.sql       /^      test1_var1 VARCHAR(64) := $$ABC$$;$/;"  v
test1_var2      input.sql       /^      test1_var2 VARCHAR(64) := $xyz$XYZ$xyz$;$/;"    v
test1_var3      input.sql       /^      test1_var3     INTEGER := 1;$/;"        v
```

tagging code including a user-defined function in a dollar quote [GH3006]:

"input.sql"

```
CREATE OR REPLACE FUNCTION fun2() RETURNS VARCHAR LANGUAGE plpgsql AS $$
DECLARE

        test2_var1 VARCHAR(64) := 'ABC2';

        test2_var2 VARCHAR(64) := 'XYZ2';

        test2_var3        INTEGER := 2;
BEGIN

        RETURN  TO_CHAR(test2_var3, '000') || test2_var1 || test2_var2;
END;
$$;
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.sql"

```
fun2    input.sql       /^CREATE OR REPLACE FUNCTION fun2() RETURNS VARCHAR LANGUAGE plpgsql AS $\$$/;" f       typeref:typename:VARCHAR
test2_var1      input.sql       /^      test2_var1 VARCHAR(64) := 'ABC2';$/;"   v
test2_var2      input.sql       /^      test2_var2 VARCHAR(64) := 'XYZ2';$/;"   v
test2_var3      input.sql       /^      test2_var3        INTEGER := 2;$/;"     v
```

tagging code including a user-defined written in JavaScript:

```
-- Derived from https://github.com/plv8/plv8/blob/r3.0alpha/sql/plv8.sql
CREATE FUNCTION test(keys text[], vals text[]) RETURNS text AS
$$

        var o = {};

        for (var i = 0; i < keys.length; i++)

                o[keys[i]] = vals[i];

        return JSON.stringify(o);
$$
LANGUAGE plv8 IMMUTABLE STRICT;
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.sql"

```
test    input.sql       /^CREATE FUNCTION test(keys text[], vals text[]) RETURNS text AS$/;"    f
o       input.sql       /^      var o = {};$/;" v
```

## KNOWN BUGS
Escape sequences ('') in a string literal may make a guest parser confused.

## SEE ALSO
ctags(1), ctags-client-tools(7)

## REFERENCES
[PL]

PostgreSQL 9.5.25 Documentation, "Chapter 39. Procedural Languages", <https://www.postgresql.org/docs/9.5/xplang.html>

[GH3006]

@bagl's comment submitted to <https://github.com/universal-ctags/ctags/issues/3006>


ctags-lang-systemtap

title: ctags-lang-systemtap(7)

text:
# ctags-lang-systemtap(7)

## NAME
ctags-lang-systemtap - Random notes about tagging SystemTap source code with Universal Ctags

## SYNOPSIS

```
ctags ... --languages=+SystemTap ...
ctags ... --language-force=SystemTap ...
ctags ... --map-SystemTap=+.stp ...
```

## DESCRIPTION
This man page gathers random notes about tagging SystemTap scripts.

### Guests
The SystemTap parser runs CPreProcessor as a guest parser on the areas surrounded by %{ and %}.

"input.stp"

```
%{
#define X 1
%}
```

"output.tags" with "--options=NONE -o - --sort=no --extras=+{guest} input.stp"

```
X       input.stp       /^#define X /;" d       file:
```

## VERSIONS

### Change since "0.0"
•

New role attached for probe kind

## SEE ALSO
ctags(1), SystemTap Language Reference <https://sourceware.org/systemtap/langref>

( <https://sourceware.org/systemtap/langref/> )