| Version: | +5.9.0 |
|---|---|
| Manual group: | Universal Ctags | +
| Manual section: | 1 | +
The ctags and etags (see -e option) programs +(hereinafter collectively referred to as ctags, +except where distinguished) generate an index (or "tag") file for a +variety of language objects found in source file(s). This tag file allows +these items to be quickly and easily located by a text editor or other +utilities (client tools). A tag signifies a language object for which an index entry is +available (or, alternatively, the index entry created for that object).
+Alternatively, ctags can generate a cross reference +file which lists, in human readable form, information about the various +language objects found in a set of source files.
+Tag index files are supported by numerous editors, which allow the user to +locate the object associated with a name appearing in a source file and +jump to the file and line which defines the name. See the manual of your +favorite editor about utilizing ctags command and +the tag index files in the editor.
+ctags is capable of generating different kinds of tags +for each of many different languages. For a complete list of supported +languages, the names by which they are recognized, and the kinds of tags +which are generated for each, see the --list-languages and --list-kinds-full +options.
+This man page describes Universal Ctags, an implementation of ctags +derived from Exuberant Ctags. The major incompatible changes between +Universal Ctags and Exuberant Ctags are enumerated in +ctags-incompatibilities(7).
+One of the advantages of Exuberant Ctags is that it allows a user to +define a new parser from the command line. Extending this capability is one +of the major features of Universal Ctags. ctags-optlib(7) +describes how the capability is extended.
+Newly introduced experimental features are not explained here. If you +are interested in such features and ctags internals, +visit https://docs.ctags.io/.
+Despite the wealth of available options, defaults are set so that +ctags is most commonly executed without any options (e.g. +"ctags *", or "ctags -R"), which will +create a tag file in the current directory for all recognized source +files. The options described below are provided merely to allow custom +tailoring to meet special needs.
+Note that spaces separating the single-letter options from their parameters +are optional.
+Note also that the boolean parameters to the long form options (those +beginning with -- and that take a [=(yes|no)] parameter) may be omitted, +in which case =yes is implied. (e.g. --sort is equivalent to --sort=yes). +Note further that =1, =on, and =true are considered synonyms for =yes, +and that =0, =off, and =false are considered synonyms for =no.
+Some options are either ignored or useful only when used while running in +etags mode (see -e option). Such options will be noted.
+<options> must precede the <source_file(s)> following the standard POSIX +convention.
+Options taking language names will accept those names in either upper or +lower case. See the --list-languages option for a complete list of the +built-in language names.
+Some options take one-letter flags as parameters (e.g. --kinds-<LANG> option). +Specifying just letters help a user create a complicated command line +quickly. However, a command line including sequences of one-letter flags +becomes difficult to understand.
+Universal Ctags accepts long-name flags in +addition to such one-letter flags. The long-name and one-letter flags can be mixed in an +option parameter by surrounding each long-name by braces. Thus, for an +example, the following three notations for --kinds-C option have +the same meaning:
+
+--kinds-C=+pLl
+--kinds-C=+{prototype}{label}{local}
+--kinds-C=+{prototype}L{local}
+
+Note that braces may be meta characters in your shell. Put +single quotes in such case.
+--list-... options shows one-letter flags and associated long-name flags.
+Universal Ctags introduces many --list-... options that provide +the internal data of Universal Ctags (See "Listing Options"). Both users and client tools may +use the data. --with-list-header and --machinable options +adjust the output of the most of --list-... options.
+The default setting (--with-list-header=yes and --machinable=no) +is for using interactively from a terminal. The header that explains +the meaning of columns is simply added to the output, and each column is +aligned in all lines. The header line starts with a hash ('#') character.
+For scripting in a client tool, --with-list-header=no and +--machinable=yes may be useful. The header is not added to the +output, and each column is separated by tab characters.
+Note the order of columns will change in the future release. +However, labels in the header will not change. So by scanning +the header, a client tool can find the index for the target +column.
+ +ctags has more options than listed here. +Options starting with an underscore character, such as --_echo=<msg>, +are not listed here. They are experimental or for debugging purpose.
+Notation: <foo> is for a variable string foo, [ ... ] for optional, +| for selection, and ( ... ) for grouping. For example +--foo[=(yes|no)]'' means ``--foo, -foo=yes, or -foo=no.
+Add <pattern> to a list of excluded files and directories. This option may +be specified as many times as desired. For each file name considered +by ctags, each pattern specified using this option +will be compared against both the complete path (e.g. +some/path/base.ext) and the base name (e.g. base.ext) of the file, thus +allowing patterns which match a given file name irrespective of its +path, or match only a specific path.
+If appropriate support is available +from the runtime library of your C compiler, then pattern may +contain the usual shell wildcards (not regular expressions) common on +Unix (be sure to quote the option parameter to protect the wildcards from +being expanded by the shell before being passed to ctags; +also be aware that wildcards can match the slash character, '/'). +You can determine if shell wildcards are available on your platform by +examining the output of the --list-features option, which will include +wildcards in the compiled feature list; otherwise, pattern is matched +against file names using a simple textual comparison.
+If <pattern> begins with the character '@', then the rest of the string +is interpreted as a file name from which to read exclusion patterns, +one per line. If pattern is empty, the list of excluded patterns is +cleared.
+Note that at program startup, the default exclude list contains names of +common hidden and system files, patterns for binary files, and directories +for which it is generally not desirable to descend while processing the +--recurse option. To see the list of built-in exclude patterns, use +--list-excludes.
+See also the description for --exclude-exception= option.
+Add <pattern> to a list of included files and directories. The pattern +affects the files and directories that are excluded by the pattern +specified with --exclude= option.
+For an example, you want ctags to ignore all files +under foo directory except foo/main.c, use the following command +line: --exclude=foo/* --exclude-exception=foo/main.c.
+Specifies a <string> to print to standard output following the tags for +each file name parsed when the --filter option is enabled. This may +permit an application reading the output of ctags +to determine when the output for each file is finished.
+Note that if the +file name read is a directory and --recurse is enabled, this string will +be printed only once at the end of all tags found for by descending +the directory. This string will always be separated from the last tag +line for the file by its terminating newline.
+This option is quite esoteric and is empty by default.
+Recurse into directories encountered in the list of supplied files.
+If the list of supplied files is empty and no file list is specified with +the -L option, then the current directory (i.e. '.') is assumed. +Symbolic links are followed by default (See --links option). If you don't like these behaviors, either +explicitly specify the files or pipe the output of find(1) into +"ctags -L -" instead. See, also, the --exclude and +--maxdepth to limit recursion.
+Note: This option is not supported on +all platforms at present. It is available if the output of the --help +option includes this option.
+Read from <file> a list of file names for which tags should be generated.
+If file is specified as '-', then file names are read from standard +input. File names read using this option are processed following file +names appearing on the command line. Options are also accepted in this +input. If this option is specified more than once, only the last will +apply.
+Note: file is read in line-oriented mode, where a new line is +the only delimiter and non-trailing white space is considered significant, +in order that file names containing spaces may be supplied +(however, trailing white space is stripped from lines); this can affect +how options are parsed if included in the input.
+Use the name specified by <tagfile> for the tag file (default is "tags", +or "TAGS" when running in etags mode). If <tagfile> is specified as '-', +then the tags are written to standard output instead.
+ctags +will stubbornly refuse to take orders if tagfile exists and +its first line contains something other than a valid tags line. This +will save your neck if you mistakenly type "ctags -f +*.c", which would otherwise overwrite your first C file with the tags +generated by the rest! It will also refuse to accept a multi-character +file name which begins with a '-' (dash) character, since this most +likely means that you left out the tag file name and this option tried to +grab the next option as the file name. If you really want to name your +output tag file -ugly, specify it as "-f ./-ugly".
+This option must +appear before the first file name. If this option is specified more +than once, only the last will apply.
+Same as --output-format=xref. +Print a tabular, human-readable cross reference (xref) file to standard +output instead of generating a tag file. The information contained in +the output includes: the tag name; the kind of tag; the line number, +file name, and source line (with extra white space condensed) of the +file which defines the tag. No tag file is written and all options +affecting tag file output will be ignored.
+Example applications for this +feature are generating a listing of all functions located in a source +file (e.g. "ctags -x --kinds-c=f file"), or generating +a list of all externally visible global variables located in a source +file (e.g. "ctags -x --kinds-c=v --extras=-F file").
+Specifies the <encoding> of the tags file. +Universal Ctags converts the encoding of input files from the encoding +specified by --input-encoding=<encoding> to this encoding.
+In addition <encoding> is specified at the top the tags file as the +value for the TAG_FILE_ENCODING pseudo-tag. The default value of +<encoding> is UTF-8.
+By default, ctags automatically selects the language +of a source file, ignoring those files whose language cannot be +determined (see "Determining file language"). This option forces the specified +language (case-insensitive; either built-in or user-defined) to be used +for every supplied file instead of automatically selecting the language +based upon its extension.
+In addition, the special value auto indicates +that the language should be automatically selected (which effectively +disables this option).
+Specifies the languages for which tag generation is enabled, with <list> +containing a comma-separated list of language names (case-insensitive; +either built-in or user-defined).
+If the first language of <list> is not +preceded by either a '+' or '-', the current list (the current settings +of enabled/disabled languages managed in ctags internally) +will be cleared before adding or removing the languages in <list>. Until a '-' is +encountered, each language in the <list> will be added to the current list.
+As either the '+' or '-' is encountered in the <list>, the languages +following it are added or removed from the current list, respectively. +Thus, it becomes simple to replace the current list with a new one, or +to add or remove languages from the current list.
+The actual list of +files for which tags will be generated depends upon the language +extension mapping in effect (see the --langmap option). Note that the most of +languages, including user-defined languages, are enabled unless explicitly +disabled using this option. Language names included in list may be any +built-in language or one previously defined with --langdef.
+The default +is all, which is also accepted as a valid argument. See the +--list-languages option for a list of the all (built-in and user-defined) +language names.
+Note --languages= option works cumulative way; the option can be +specified with different arguments multiple times in a command line.
+Adds ('+') or removes ('-') an alias <pattern> to a language specified +with <LANG>. ctags refers to the alias pattern in +"Determining file language" stage.
+The parameter <pattern> is not a list. Use this option multiple +times in a command line to add or remove multiple alias +patterns.
+To restore the default language aliases, specify default.
+Using all for <LANG> has meaning in following two cases:
+Controls how file names are mapped to languages (see the --list-maps +option). Each comma-separated <map> consists of the language name (either +a built-in or user-defined language), a colon, and a list of file +extensions and/or file name patterns. A file extension is specified by +preceding the extension with a period (e.g. .c). A file name pattern +is specified by enclosing the pattern in parentheses (e.g. +([Mm]akefile)).
+If appropriate support is available from the runtime +library of your C compiler, then the file name pattern may contain the usual +shell wildcards common on Unix (be sure to quote the option parameter to +protect the wildcards from being expanded by the shell before being +passed to ctags). You can determine if shell wildcards +are available on your platform by examining the output of the +--list-features option, which will include wildcards in the compiled +feature list; otherwise, the file name patterns are matched against +file names using a simple textual comparison.
+When mapping a file extension with --langmap option, +it will first be unmapped from any other languages. (--map-<LANG> +option provides more fine-grained control.)
+If the first character in a <map> is a plus sign ('+'), then the extensions and +file name patterns in that map will be appended to the current map +for that language; otherwise, the map will replace the current map. +For example, to specify that only files with extensions of .c and .x are +to be treated as C language files, use --langmap=c:.c.x; to also add +files with extensions of .j as Java language files, specify +--langmap=c:.c.x,java:+.j. To map makefiles (e.g. files named either +Makefile, makefile, or having the extension .mak) to a language +called make, specify --langmap=make:([Mm]akefile).mak. To map files +having no extension, specify a period not followed by a non-period +character (e.g. '.', ..x, .x.).
+To clear the mapping for a +particular language (thus inhibiting automatic generation of tags for +that language), specify an empty extension list (e.g. --langmap=fortran:). +To restore the default language mappings for a particular language, +supply the keyword default for the mapping. To specify restore the +default language mappings for all languages, specify --langmap=default.
+Note that file name patterns are tested before file extensions when inferring +the language of a file. This order of Universal Ctags is different from +Exuberant Ctags. See ctags-incompatibilities(7) for the background of +this incompatible change.
+This option provides the way to control mapping(s) of file names to +languages in a more fine-grained way than --langmap option.
+In ctags, more than one language can map to a +file name <pattern> or file <extension> (N:1 map). Alternatively, +--langmap option handle only 1:1 map, only one language +mapping to one file name <pattern> or file <extension>. A typical N:1 +map is seen in C++ and ObjectiveC language; both languages have +a map to .h as a file extension.
+A file extension is specified by preceding the extension with a period (e.g. .c). +A file name pattern is specified by enclosing the pattern in parentheses (e.g. +([Mm]akefile)). A prefixed plus ('+') sign is for adding, and +minus ('-') is for removing. No prefix means replacing the map of <LANG>.
+Unlike --langmap, <extension> (or <pattern>) is not a list. +--map-<LANG> takes one extension (or pattern). However, +the option can be specified with different arguments multiple times +in a command line.
+See "TAG ENTRIES" about fields, kinds, roles, and extras.
+Determines the type of EX command used to locate tags in the source +file. [Ignored in etags mode]
+The valid values for type (either the entire word or the first letter +is accepted) are:
+Use only line numbers in the tag file for locating tags. This has +four advantages:
+However, this option has one significant drawback: changes to the +source files can cause the line numbers recorded in the tag file +to no longer correspond to the lines in the source file, causing +jumps to some tags to miss the target definition by one or more +lines. Basically, this option is best used when the source code +to which it is applied is not subject to change. Selecting this +option type causes the following options to be ignored: -B, -F.
+number type is ignored in Xref and JSON output formats. Use +--_xformat="...%n" for Xref output format, or --fields=+n-P for +JSON output format.
+ +In this mode, patterns are generally used with a few exceptions. +For C, line numbers are used for macro definition tags. For Fortran, line numbers +are used for common blocks because their corresponding source lines +are generally identical, making pattern searches useless +for finding all matches.
+This was the default format generated by the original ctags and is, +therefore, retained as the default for this option.
+Specifies whether to include extra tag entries for certain kinds of +information. See also "Extras" subsection to know what are extras.
+The parameter <flags> is a set of one-letter flags (and/or long-name flags), each +representing one kind of extra tag entry to include in the tag file. +If flags is preceded by either the '+' or '-' character, the effect of +each flag is added to, or removed from, those currently enabled; +otherwise the flags replace any current settings. All entries are +included if '*' is given.
+This --extras= option is for controlling extras common in all +languages (or language-independent extras). Universal Ctags also +supports language-specific extras. (See "Language-specific fields and +extras" about the concept). Use --extras-<LANG>= option for +controlling them.
+Specifies whether to include extra tag entries for certain kinds of +information for language <LANG>. Universal Ctags +introduces language-specific extras. See "Language-specific fields and +extras" about the concept. This option is for controlling them.
+Specifies all as <LANG> to apply the parameter <flags> to all +languages; all extras are enabled with specifying '*' as the +parameter flags. If specifying nothing as the parameter flags +(--extras-all=), all extras are disabled. These two combinations +are useful for testing.
+Check the output of the --list-extras=<LANG> option for the +extras of specific language <LANG>.
+Specifies which language-independent fields are to be included in the tag +entries. Language-independent fields are extension fields which are common +in all languages. See "TAG FILE FORMAT" section, and "Extension fields" +subsection, for details of extension fields.
+The parameter <flags> is a set of one-letter or long-name flags, +each representing one type of extension field to include. +Each flag or group of flags may be preceded by either '+' to add it +to the default set, or '-' to exclude it. In the absence of any +preceding '+' or '-' sign, only those fields explicitly listed in flags +will be included in the output (i.e. overriding the default set). All +fields are included if '*' is given.
+This option is ignored if the +option --format=1 (legacy tag file format) has been specified.
+Use --fields-<LANG>= option for controlling language-specific fields.
+Specifies which language-specific fields are to be included in +the tag entries. Universal Ctags +supports language-specific fields. (See "Language-specific fields and +extras" about the concept).
+Specify all as <LANG> to apply the parameter <flags> to all +languages; all fields are enabled with specifying '*' as the +parameter flags. If specifying nothing as the parameter <flags> +(i.e. --fields-all=), all fields are disabled. These two combinations +are useful for testing.
+See the description of --fields=[+|-][<flags>|*] about <flags>.
+Use --fields= option for controlling language-independent fields.
+Specifies a list of language-specific <kinds> of tags (or kinds) to +include in the output file for a particular language, where <LANG> is +case-insensitive and is one of the built-in language names (see the +--list-languages option for a complete list).
+The parameter <kinds> is a group +of one-letter or long-name flags designating kinds of tags (particular to the language) +to either include or exclude from the output. The specific sets of +flags recognized for each language, their meanings and defaults may be +list using the --list-kinds-full option.
+Each letter or group of letters +may be preceded by either '+' to add it to, or '-' to remove it from, +the default set. In the absence of any preceding '+' or '-' sign, only +those kinds explicitly listed in kinds will be included in the output +(i.e. overriding the default for the specified language).
+Specify '*' as the parameter to include all kinds implemented +in <LANG> in the output. Furthermore if all is given as <LANG>, +specification of the parameter kinds affects all languages defined +in ctags. Giving all makes sense only when '*' or +'F' is given as the parameter kinds.
+As an example for the C language, in order to add prototypes and +external variable declarations to the default set of tag kinds, +but exclude macros, use --kinds-c=+px-d; to include only tags for +functions, use --kinds-c=f.
+Some kinds of C and C++ languages are synchronized; enabling +(or disabling) a kind in one language enables the kind having +the same one-letter and long-name in the other language. See also the +description of MASTER column of --list-kinds-full.
+Truncate patterns of tag entries after <N> characters. Disable by setting to 0 +(default is 96).
+An input source file with long lines and multiple tag matches per +line can generate an excessively large tags file with an +unconstrained pattern length. For example, running ctags on a +minified JavaScript source file often exhibits this behavior.
+The truncation avoids cutting in the middle of a UTF-8 code point +spanning multiple bytes to prevent writing invalid byte sequences from +valid input files. This handling allows for an extra 3 bytes above the +configured limit in the worse case of a 4 byte code point starting +right before the limit. Please also note that this handling is fairly +naive and fast, and although it is resistant against any input, it +requires a valid input to work properly; it is not guaranteed to work +as the user expects when dealing with partially invalid UTF-8 input. +This also partially affect non-UTF-8 input, if the byte sequence at +the truncation length looks like a multibyte UTF-8 sequence. This +should however be rare, and in the worse case will lead to including +up to an extra 3 bytes above the limit.
+Put UCTAGS as prefix for the name of fields newly introduced in +Universal Ctags.
+Some fields are newly introduced in Universal Ctags and more will +be introduced in the future. Other tags generators may also +introduce their specific fields.
+In such a situation, there is a concern about conflicting field +names; mixing tags files generated by multiple tags generators +including Universal Ctags is difficult. This option provides a +workaround for such station.
++$ ctags --fields='{line}{end}' -o - hello.c +main hello.c /^main(int argc, char **argv)$/;" f line:3 end:6 +$ ctags --put-field-prefix --fields='{line}{end}' -o - hello.c +main hello.c /^main(int argc, char **argv)$/;" f line:3 UCTAGSend:6 ++
In the above example, the prefix is put to end field which is +newly introduced in Universal Ctags.
+Specifies a list of kind-specific roles of tags to include in the +output file for a particular language. +<kind> specifies the kind where the <roles> are defined. +<LANG> specifies the language where the kind is defined. +Each role in <roles> must be surrounded by braces (e.g. {system} +for a role named "system").
+Like --kinds-<LANG> option, '+' is for adding the role to the +list, and '-' is for removing from the list. '*' is for including +all roles of the kind to the list. The option with no argument +makes the list empty.
+Both a one-letter flag or a long name flag surrounded by braces are +acceptable for specifying a kind (e.g. --roles-C.h=+{system}{local} +or --roles-C.{header}=+{system}{local}). '*' can be used for <KIND> +only for adding/removing all roles of all kinds in a language to/from +the list (e.g. --roles-C.*=* or --roles-C.*=).
+all can be used for <LANG> only for adding/removing all roles of +all kinds in all languages to/from the list +(e.g. --roles-all.*=* or --roles-all.*=).
+Specifies how the file paths recorded in the tag file. +The default is yes when running in etags mode (see +the -e option), no otherwise.
+Uses slash ('/') character as filename separators instead of backslash +('\') character when printing input: field. +The default is yes for the default "u-ctags" output format, and +no for the other formats.
+This option is available on MS Windows only.
+Read additional options from file or directory.
+ctags searches <pathname> in the optlib path list +first. If ctags cannot find a file or directory +in the list, ctags reads a file or directory +at the specified <pathname>.
+If a file is specified, it should contain one option per line. If +a directory is specified, files suffixed with .ctags under it +are read in alphabetical order.
+As a special case, if --options=NONE is specified as the first +option on the command line, preloading is disabled; the option +will disable the automatic reading of any configuration options +from a file (see "FILES").
+See ctags-optlib(7) for details of each option.
+Indicates a preference as to whether code within an "#if 0" branch of a +preprocessor conditional should be examined for non-macro tags (macro +tags are always included). Because the intent of this construct is to +disable code, the default value of this option is no (disabled).
+Note that this +indicates a preference only and does not guarantee skipping code within +an "#if 0" branch, since the fall-back algorithm used to generate +tags when preprocessor conditionals are too complex follows all branches +of a conditional.
+Specifies whether #line directives should be recognized. These are +present in the output of a preprocessor and contain the line number, and +possibly the file name, of the original source file(s) from which the +preprocessor output file was generated. This option is off by default.
+When enabled, this option will +cause ctags to generate tag entries marked with the +file names and line numbers of their locations original source file(s), +instead of their actual locations in the preprocessor output. The actual +file names placed into the tag file will have the same leading path +components as the preprocessor output file, since it is assumed that +the original source files are located relative to the preprocessor +output file (unless, of course, the #line directive specifies an +absolute path).
+Note: This option is generally +only useful when used together with the --excmd=number (-n) option. +Also, you may have to use either the --langmap or --language-force option +if the extension of the preprocessor output file is not known to +ctags.
+Specifies a <list> of file extensions, separated by periods, which are +to be interpreted as include (or header) files. To indicate files having +no extension, use a period not followed by a non-period character +(e.g. '.', ..x, .x.).
+This option only affects how the scoping of +particular kinds of tags are interpreted (i.e. whether or not they are +considered as globally visible or visible only within the file in which +they are defined); it does not map the extension to any particular +language. Any tag which is located in a non-include file and cannot be +seen (e.g. linked to) from another file is considered to have file-limited +(e.g. static) scope. No kind of tag appearing in an include file +will be considered to have file-limited scope.
+If the first character in the list is '+', then the extensions in the list will be +appended to the current list; otherwise, the list will replace the +current list. See, also, the fileScope/F flag of --extras option.
+The default list is +.h.H.hh.hpp.hxx.h++.inc.def. To restore the default list, specify "-h +default".
+Note that if an extension supplied to this option is not +already mapped to a particular language (see "Determining file language", above), +you will also need to use either the --map-<LANG>, --langmap or +--language-force option.
+Specifies a <identifier-list> of identifiers which are to be specially handled while +parsing C and C++ source files. This option is specifically provided +to handle special cases arising through the use of preprocessor macros. +When the identifiers listed are simple identifiers, these identifiers +will be ignored during parsing of the source files.
+If an identifier is +suffixed with a '+' character (i.e. "-I FOO+"), ctags will also +ignore any parenthesis-enclosed argument list which may immediately +follow the identifier in the source files. See the example of "-I +MODULE_VERSION+" below.
+If two identifiers are +separated with the '=' character (i.e. -I FOO=BAR), the first identifiers is replaced by +the second identifiers for parsing purposes. The list of identifiers may +be supplied directly on the command line or read in from a separate file. +See the example of "-I CLASS=class" below.
+If the first character of <identifier-list> is '@', '.' or a pathname +separator ('/' or '\'), or the first two characters specify a drive +letter (e.g. C:), the parameter <identifier-list> will be interpreted as +a filename from which to read a list of identifiers, one per input line.
+Otherwise, <identifier-list> is a list of identifiers (or identifier +pairs) to be specially handled, each delimited by either a comma or +by white space (in which case the list should be quoted to keep the +entire list as one command line argument).
+Multiple -I options may be +supplied. To clear the list of ignore identifiers, supply a single +dash ('-') for <identifier-list>.
+This feature is useful when preprocessor macros are used in such a way +that they cause syntactic confusion due to their presence. Indeed, +this is the best way of working around a number of problems caused by +the presence of syntax-busting macros in source files (see "CAVEATS"). +Some examples will illustrate this point.
++int foo ARGDECL4(void *, ptr, long int, nbytes) ++
In the above example, the macro ARGDECL4 would be mistakenly +interpreted to be the name of the function instead of the correct name +of foo. Specifying "-I ARGDECL4" results in the correct behavior.
++/* creates an RCS version string in module */ +MODULE_VERSION("$Revision$") ++
In the above example the macro invocation looks too much like a function +definition because it is not followed by a semicolon (indeed, it +could even be followed by a global variable definition that would look +much like a K&R style function parameter declaration). In fact, this +seeming function definition could possibly even cause the rest of the +file to be skipped over while trying to complete the definition. +Specifying "-I MODULE_VERSION+" would avoid such a problem.
++CLASS Example { + // your content here +}; ++
The example above uses CLASS as a preprocessor macro which expands to +something different for each platform. For instance CLASS may be +defined as class __declspec(dllexport) on Win32 platforms and simply +class on UNIX. Normally, the absence of the C++ keyword class +would cause the source file to be incorrectly parsed. Correct behavior +can be restored by specifying "-I CLASS=class".
+Set a <LANG> specific parameter, a parameter specific to the <LANG>.
+Available parameters can be listed with --list-params.
+Lists the extras recognized for either the specified <language> or +all languages. See "Extras" subsection to know what are extras. +all is used as default value if the option argument is omitted.
+An extra can be enabled or disabled with --extras= for common +extras in all languages, or --extras-<LANG>= for the specified +language. These option takes one-letter flag or long-name flag as a parameter +for specifying an extra.
+The meaning of columns in output are as follows:
+Lists the fields recognized for either the specified <language> or +all languages. See "Extension fields" subsection to know what are fields. +all is used as default value if the option argument is omitted.
+The meaning of columns are as follows:
+Whether this field can be disabled or not in tags output.
+Some fields are printed always in tags output. +They have yes as the value for this column.
+Unlike the tag output mode, JSON output mode allows disabling +any fields.
+Subset of --list-kinds-full. This option is kept for +backward-compatibility with Exuberant Ctags.
+This option prints only LETTER, DESCRIPTION, and ENABLED fields +of --list-kinds-full output. However, the presentation of +ENABLED column is different from that of --list-kinds-full +option; [off] follows after description if the kind is disabled, +and nothing follows if enabled. The most of all kinds are enabled +by default.
+The critical weakness of this option is that this option does not +print the name of kind. Universal Ctags introduces +--list-kinds-full because it considers that names are +important.
+This option does not work with --machinable nor +--with-list-header.
+Lists the tag kinds recognized for either the specified <language> +or all languages, and then exits. See "Kinds" subsection to +learn what kinds are. +all is used as default value if the option argument is omitted.
+Each kind of tag recorded in the tag file is represented by a +one-letter flag, or a long-name flag. They are also used to filter the tags +placed into the output through use of the --kinds-<LANG> +option.
+The meaning of columns are as follows:
+The master parser controlling enablement of the kind. +A kind belongs to a language (owner) in Universal Ctags; +enabling and disabling a kind in a language has no effect on +a kind in another language even if both kinds has the +same one-letter flag and/or the same long-name flag. In other words, +the namespace of kinds are separated by language.
+However, Exuberant Ctags does not separate the kinds of C and +C++. Enabling/disabling kindX in C language enables/disables a +kind in C++ language having the same long-name flag with kindX. To +emulate this behavior in Universal Ctags, a concept named +master parser is introduced. Enabling/disabling some kinds +are synchronized under the control of a master language.
++$ ctags --kinds-C=+'{local}' --list-kinds-full \ + | grep -E '^(#|C\+\+ .* local)' +#LANGUAGE LETTER NAME ENABLED REFONLY NROLES MASTER DESCRIPTION +C++ l local yes no 0 C local variables +$ ctags --kinds-C=-'{local}' --list-kinds-full \ + | grep -E '^(#|C\+\+ .* local)' +#LANGUAGE LETTER NAME ENABLED REFONLY NROLES MASTER DESCRIPTION +C++ l local no no 0 C local variables ++
You see ENABLED field of local kind of C++ language is changed +Though local kind of C language is enabled/disabled. If you swap the languages, you +see the same result.
+ +Lists the names of the languages understood by ctags, +and then exits. These language names are case insensitive and may be +used in many other options like --language-force, +--languages, --kinds-<LANG>, --regex-<LANG>, and so on.
+Each language listed is disabled if followed by [disabled]. +To use the parser for such a language, specify the language as an +argument of --languages=+ option.
+--machinable and --with-list-header options are ignored if they are +specified with this option.
+Lists file name patterns and the file extensions which associate a file +name with a language for either the specified <language> or all +languages, and then exits. +all is used as default value if the option argument is omitted.
+To list the file extensions or file name patterns individually, use +--list-map-extensions or --list-map-patterns option. +See the --langmap option, and "Determining file language", above.
+This option does not work with --machinable nor +--with-list-header.
+List the roles for either the specified <language> or all languages. +all is used as default value if the option argument is omitted.
+If the parameter <kindspecs> is given after the parameter +<language> or all with concatenating with '.', list only roles +defined in the kinds. Both one-letter flags and long name flags surrounded +by braces are acceptable as the parameter <kindspecs>.
+The meaning of columns are as follows:
+Prints statistics about the source files read and the tag file written +during the current invocation of ctags. This option +is no by default.
+The extra value prints parser specific statistics for parsers +gathering such information.
+These options are kept for backward-compatibility with Exuberant Ctags.
+As ctags considers each source file name in turn, it tries to +determine the language of the file by applying tests described in +"Determining file language".
+If a language was identified, the file is opened and then the appropriate +language parser is called to operate on the currently open file. The parser +parses through the file and adds an entry to the tag file for each +language object it is written to handle. See "TAG FILE FORMAT", below, +for details on these entries.
+This implementation of ctags imposes no formatting +requirements on C code as do legacy implementations. Older implementations +of ctags tended to rely upon certain formatting assumptions in order to +help it resolve coding dilemmas caused by preprocessor conditionals.
+In general, ctags tries to be smart about conditional +preprocessor directives. If a preprocessor conditional is encountered +within a statement which defines a tag, ctags follows +only the first branch of that conditional (except in the special case of +#if 0, in which case it follows only the last branch). The reason for +this is that failing to pursue only one branch can result in ambiguous +syntax, as in the following example:
++#ifdef TWO_ALTERNATIVES +struct { +#else +union { +#endif + short a; + long b; +} ++
Both branches cannot be followed, or braces become unbalanced and +ctags would be unable to make sense of the syntax.
+If the application of this heuristic fails to properly parse a file, +generally due to complicated and inconsistent pairing within the +conditionals, ctags will retry the file using a +different heuristic which does not selectively follow conditional +preprocessor branches, but instead falls back to relying upon a closing +brace ('}') in column 1 as indicating the end of a block once any brace +imbalance results from following a #if conditional branch.
+ctags will also try to specially handle arguments lists +enclosed in double sets of parentheses in order to accept the following +conditional construct:
++extern void foo __ARGS((int one, char two)); ++
Any name immediately preceding the '((' will be automatically ignored and +the previous name will be used.
+C++ operator definitions are specially handled. In order for consistency +with all types of operators (overloaded and conversion), the operator +name in the tag file will always be preceded by the string "operator " +(i.e. even if the actual operator definition was written as "operator<<").
+After creating or appending to the tag file, it is sorted by the tag name, +removing identical tag lines.
+Unless the --language-force option is specified, the language of each source +file is automatically selected based upon a mapping of file names to +languages. The mappings in effect for each language may be displayed using +the --list-maps option and may be changed using the --langmap or +--map-<LANG> options.
+If the name of a file is not mapped to a language, ctags tries +to heuristically guess the language for the file by inspecting its content.
+All files that have no file name mapping and no guessed parser are +ignored. This permits running ctags on all files in +either a single directory (e.g. "ctags *"), or on +all files in an entire source directory tree +(e.g. "ctags -R"), since only those files whose +names are mapped to languages will be scanned.
+An extension may be mapped to multiple parsers. For example, .h +are mapped to C++, C and ObjectiveC. These mappings can cause +issues. ctags tries to select the proper parser +for the source file by applying heuristics to its content, however +it is not perfect. In case of issues one can use --language-force=<language>, +--langmap=<map>[,<map>[...]], or the --map-<LANG>=[+|-]<extension>|<pattern> +options. (Some of the heuristics are applied whether --guess-language-eagerly +is given or not.)
+ +If ctags cannot select a parser from the mapping of file names, +various heuristic tests are conducted to determine the language:
+The first line of the file is checked to see if the file is a #! +script for a recognized language. ctags looks for +a parser having the same name.
+If ctags finds no such parser, +ctags looks for the name in alias lists. For +example, consider if the first line is #!/bin/sh. Though +ctags has a "shell" parser, it doesn't have a "sh" +parser. However, sh is listed as an alias for shell, therefore +ctags selects the "shell" parser for the file.
+An exception is env. If env is specified (for example +"#!/usr/bin/env python"), ctags +reads more lines to find real interpreter specification.
+To display the list of aliases, use --list-aliases option. +To add an item to the list or to remove an item from the list, use the +--alias-<LANG>=+<pattern> or --alias-<LANG>=-<pattern> option +respectively.
+The Emacs editor has multiple editing modes specialized for programming +languages. Emacs can recognize a marker called modeline in a file +and utilize the marker for the mode selection. This heuristic test does +the same as what Emacs does.
+ctags treats MODE as a name of interpreter and applies the same +rule of "interpreter" testing if the first line has one of +the following patterns:
++-*- mode: MODE -*- ++
or
++-*- MODE -*- ++
Emacs editor recognizes another marker at the end of file as a +mode specifier. This heuristic test does the same as what Emacs does.
+ctags treats MODE as a name of an interpreter and applies the same +rule of "interpreter" heuristic testing, if the lines at the tail of the file +have the following pattern:
++Local Variables: +... +mode: MODE +... +End: ++
3000 characters are sought from the end of file to find the pattern.
+Like the modeline of the Emacs editor, Vim editor has the same concept. +ctags treats TYPE as a name of interpreter and applies the same +rule of "interpreter" heuristic testing if the last 5 lines of the file +have one of the following patterns:
++filetype=TYPE ++
or
++ft=TYPE ++
Looking into the file contents is a more expensive operation than file +name matching. So ctags runs the testings in limited +conditions. "interpreter" testing is enabled only when a file is an +executable or the --guess-language-eagerly (-G in short) option is +given. The other heuristic tests are enabled only when -G option is +given.
+The --print-language option can be used just to print the results of +parser selections for given files instead of generating a tags file.
+Examples:
++$ ctags --print-language config.h.in input.m input.unknown +config.h.in: C++ +input.m: MatLab +input.unknown: NONE ++
NONE means that ctags does not select any parser for the file.
+This section describes the tag file format briefly. See tags(5) and +ctags-client-tools(7) for more details.
+When not running in etags mode, each entry in the tag file consists of a +separate line, each looking like this, called regular tags, in the most general case:
++<tag_name><TAB><file_name><TAB><ex_cmd>;"<TAB><extension_fields> ++
The fields and separators of these lines are specified as follows:
++++
+- +
<tag_name>: tag name
+- +
<TAB>: single tab character
+- +
<file_name>: name of the file in which the object associated with the tag is located
+- +
<TAB>: single tab character
+- +
<ex_cmd>: EX command used to locate the tag within the file; generally a +search pattern (either /pattern/ or ?pattern?) or line number (see +--excmd=<type> option).
+- +
;"<TAB><extension_fields>: a set of extension fields. See +"Extension fields" for more details.
+Tag file format 2 (see --format) extends the EX command +to include the extension fields embedded in an EX comment immediately appended +to the EX command, which leaves it backward-compatible with original +vi(1) implementations.
+
A few special tags, called pseudo tags, are written into the tag file for internal purposes.
++!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;" to lines/ +!_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/ +... ++
--pseudo-tags=[+|-](<pseudo-tag>|*) option enables or disables emitting pseudo-tags.
+See the output of "ctags --list-pseudo-tags" for the list of +the kinds. +See also tags(5) and ctags-client-tools(7) for more details of the pseudo tags.
+These tags are composed in such a way that they always sort to the top of +the file. Therefore, the first two characters of these tags are used a magic +number to detect a tag file for purposes of determining whether a +valid tag file is being overwritten rather than a source file.
+Note that the name of each source file will be recorded in the tag file +exactly as it appears on the command line. Therefore, if the path you +specified on the command line was relative to the current directory, then +it will be recorded in that same manner in the tag file. See, however, +the --tag-relative=(yes|no|always|never) option for how this behavior can be +modified.
+A tag is an index for a language object. The concept of a tag and related +items in Exuberant Ctags are refined and extended in Universal Ctags.
+A tag is categorized into definition tags or reference tags. +In general, Exuberant Ctags only tags definitions of +language objects: places where newly named language objects are introduced. +Universal Ctags, on the other hand, can also tag references of language +objects: places where named language objects are used. However, support +for generating reference tags is new and limited to specific areas of +specific languages in the current version.
+A tag can record various information, called extension fields.
+Extension fields are tab-separated key-value pairs appended to the end of +the EX command as a comment, as described above. These key value pairs +appear in the general form key:value.
+In addition, information on the scope of the tag definition may be +available, with the key portion equal to some language-dependent construct +name and its value the name declared for that construct in the program. +This scope entry indicates the scope in which the tag was found. +For example, a tag generated for a C structure member would have a scope +looking like struct:myStruct.
+--fields=[+|-][<flags>|*] and --fields-(<LANG>|all)=[+|-][<flags>|*] options specifies +which available extension fields are to be included in the tag entries.
+See the output of "ctags --list-fields" for the list of +extension fields. +The essential fields are name, input, pattern, and line. +The meaning of major fields is as follows (long-name flag/one-letter flag):
+kind is a field which represents the kind of language object +specified by a tag. Kinds used and defined are very different between +parsers. For example, C language defines macro, function, +variable, typedef, etc.
+--kinds-(<LANG>|all)=[+|-](<kinds>|*) option specifies a list of language-specific +kinds of tags (or kinds) to include in the output file for a particular +language.
+See the output of "ctags --list-kinds-full" for the complete +list of the kinds.
+Its value is either one of the +corresponding one-letter flags or a long-name flag. It is permitted +(and is, in fact, the default) for the key portion of this field to be +omitted. The optional behaviors are controlled with the --fields option as follows.
++$ ctags -o - kinds.c +foo kinds.c /^int foo() {$/;" f typeref:typename:int +$ ctags --fields=+k -o - kinds.c +foo kinds.c /^int foo() {$/;" f typeref:typename:int +$ ctags --fields=+K -o - kinds.c +foo kinds.c /^int foo() {$/;" function typeref:typename:int +$ ctags --fields=+z -o - kinds.c +foo kinds.c /^int foo() {$/;" kind:f typeref:typename:int +$ ctags --fields=+zK -o - kinds.c +foo kinds.c /^int foo() {$/;" kind:function typeref:typename:int ++
Role is a newly introduced concept in Universal Ctags. Role is a +concept associated with reference tags, and is not implemented widely yet.
+As described previously in "Kinds", the kind field represents the type +of language object specified with a tag, such as a function vs. a variable. +Specific kinds are defined for reference tags, such as the C++ kind header for +header file, or Java kind package for package statements. For such reference +kinds, a roles field can be added to distinguish the role of the reference +kind. In other words, the kind field identifies the what of the language +object, whereas the roles field identifies the how of a referenced language +object. Roles are only used with specific kinds.
+For a definition tag, this field takes def as a value.
+For example, Baz is tagged as a reference tag with kind package and with +role imported with the following code.
++package Bar; +import Baz; + +class Foo { + // ... +} ++
+$ ctags --fields=+KEr -uo - roles.java +Bar roles.java /^package Bar;$/;" package roles:def +Foo roles.java /^class Foo {$/;" class roles:def +$ ctags --fields=+EKr --extras=+r -uo - roles.java +Bar roles.java /^package Bar;$/;" package roles:def +Baz roles.java /^import Baz;$/;" package roles:imported extras:reference +Foo roles.java /^class Foo {$/;" class roles:def ++
--roles-(<LANG>|all).(<kind>|all)=[+|-][<roles>|*] option specifies a list of kind-specific +roles of tags to include in the output file for a particular language.
+Inquire the output of "ctags --list-roles" for the list of +roles.
+Generally, ctags tags only language objects appearing +in source files, as is. In other words, a value for a name: field +should be found on the source file associated with the name:. An +extra type tag (extra) is for tagging a language object with a processed +name, or for tagging something not associated with a language object. A typical +extra tag is qualified, which tags a language object with a +class-qualified or scope-qualified name.
+--extras-(<LANG>|all)=[+|-][<flags>|*] option specifies +whether to include extra tag entries for certain kinds of information.
+Inquire the output of ctags --list-extras for the list of extras. +The meaning of major extras is as follows (long-name flag/one-letter flag):
+Include an entry for the language object that has no name like lambda +function. This extra has no one-letter flag and is enabled by +default.
+The extra tag is useful as a placeholder to fill scope fields +for language objects defined in a language object with no name.
++struct { + double x, y; +} p = { .x = 0.0, .y = 0.0 }; ++
'x' and 'y' are the members of a structure. When filling the scope +fields for them, ctags has trouble because the struct +where 'x' and 'y' belong to has no name. For overcoming the trouble, +ctags generates an anonymous extra tag for the struct +and fills the scope fields with the name of the extra tag.
++$ ctags --fields=-f -uo - input.c +__anon9f26d2460108 input.c /^struct {$/;" s +x input.c /^ double x, y;$/;" m struct:__anon9f26d2460108 +y input.c /^ double x, y;$/;" m struct:__anon9f26d2460108 +p input.c /^} p = { .x = 0.0, .y = 0.0 };$/;" v typeref:struct:__anon9f26d2460108 ++
The above tag output has __anon9f26d2460108 as an anonymous extra tag. +The typeref field of 'p' also receives the benefit of it.
+Indicates whether tags scoped only for a single file (i.e. tags which +cannot be seen outside of the file in which they are defined, such as +language objects with static modifier of C language) should be included +in the output. See also the -h option.
+This extra tag is enabled by default. Add --extras=-F option not to +output tags scoped only for a single-file. This is the replacement for +--file-scope option of Exuberant Ctags.
++static int f() { + return 0; +} +int g() { + return 0; +} ++
+$ ctags -uo - filescope.c +f filescope.c /^static int f() {$/;" f typeref:typename:int file: +g filescope.c /^int g() {$/;" f typeref:typename:int +$ ctags --extras=-F -uo - filescope.c +g filescope.c /^int g() {$/;" f typeref:typename:int ++
Include an entry for the base file name of every source file +(e.g. example.c), which addresses the first line of the file. +This flag is the replacement for --file-tags hidden option of +Exuberant Ctags.
+If the end: field is enabled, the end line number of the file can be +attached to the tag. (However, ctags omits the end: field +if no newline is in the file like an empty file.)
+By default, ctags doesn't create the inputFile/f extra +tag for the source file when ctags doesn't find a parser +for it. Enabling Unknown parser with --languages=+Unknown forces +ctags to create the extra tags for any source files.
+The etags mode enables the Unknown parser implicitly.
+Include an extra class-qualified or namespace-qualified tag entry +for each tag which is a member of a class or a namespace.
+This may allow easier location of a specific tags when +multiple occurrences of a tag name occur in the tag file. +Note, however, that this could potentially more than double +the size of the tag file.
+The actual form of the qualified tag depends upon the language +from which the tag was derived (using a form that is most +natural for how qualified calls are specified in the +language). For C++ and Perl, it is in the form +class::member; for Eiffel and Java, it is in the form +class.member.
+Note: Using backslash characters as separators forming +qualified name in PHP. However, in tags output of +Universal Ctags, a backslash character in a name is escaped +with a backslash character. See tags(5) about the escaping.
+The following example demonstrates the qualified extra tag.
++class point { + double x; +}; ++
For the above source file, ctags tags point and x by +default. If the qualified extra is enabled from the command line +(--extras=+q), then point.x is also tagged even though the string +"point.x" is not in the source code.
++$ ctags --fields=+K -uo - qualified.java +point qualified.java /^class point {$/;" class +x qualified.java /^ double x;$/;" field class:point +$ ctags --fields=+K --extras=+q -uo - qualified.java +point qualified.java /^class point {$/;" class +x qualified.java /^ double x;$/;" field class:point +point.x qualified.java /^ double x;$/;" field class:point ++
Include reference tags. See "TAG ENTRIES" about reference tags.
+The following example demonstrates the reference extra tag.
++#include <stdio.h> +#include "utils.h" +#define X +#undef X ++
The roles:system or roles:local fields will be +added depending on whether the include file name begins with '<' or not.
+"#define X" emits a definition tag. On the other hand "#undef X" emits a +reference tag.
++$ ctags --fields=+EKr -uo - inc.c +X inc.c /^#define X$/;" macro file: roles:def extras:fileScope +$ ctags --fields=+EKr --extras=+r -uo - inc.c +stdio.h inc.c /^#include <stdio.h>/;" header roles:system extras:reference +utils.h inc.c /^#include "utils.h"/;" header roles:local extras:reference +X inc.c /^#define X$/;" macro file: roles:def extras:fileScope +X inc.c /^#undef X$/;" macro file: roles:undef extras:fileScope,reference ++
Exuberant Ctags has the concept of fields and extras. They are common +between parsers of different languages. Universal Ctags extends this concept +by providing language-specific fields and extras.
+ + +vi(1) will, by default, expect a tag file by the name tags in the current +directory. Once the tag file is built, the following commands exercise +the tag indexing feature:
+emacs(1) will, by default, expect a tag file by the name TAGS in the +current directory. Once the tag file is built, the following commands +exercise the tag indexing feature:
+For more commands, see the Tags topic in the Emacs info document.
+NEdit version 5.1 and later can handle the new extended tag file format +(see --format).
+NEdit 5.1 can read multiple tag files from different +directories. Setting the X resource nedit.tagFile to the name of a tag +file instructs NEdit to automatically load that tag file at startup time.
+Because ctags is neither a preprocessor nor a compiler, +use of preprocessor macros can fool ctags into either +missing tags or improperly generating inappropriate tags. Although +ctags has been designed to handle certain common cases, +this is the single biggest cause of reported problems. In particular, +the use of preprocessor constructs which alter the textual syntax of C +can fool ctags. You can work around many such problems +by using the -I option.
+Note that since ctags generates patterns for locating +tags (see the --excmd option), it is entirely possible that the wrong line +may be found by your editor if there exists another source line which is +identical to the line containing the tag. The following example +demonstrates this condition:
++int variable; + +/* ... */ +void foo(variable) +int variable; +{ + /* ... */ +} ++
Depending upon which editor you use and where in the code you happen to be, +it is possible that the search pattern may locate the local parameter +declaration before it finds the actual global variable definition, +since the lines (and therefore their search patterns) are +identical.
+This can be avoided by use of the --excmd=n option.
+ctags has more options than ls(1).
+ctags assumes the input file is written in the correct +grammar. Otherwise output of ctags is undefined. In other words it has garbage +in, garbage out (GIGO) feature.
+ +When parsing a C++ member function definition (e.g. className::function), +ctags cannot determine whether the scope specifier +is a class name or a namespace specifier and always lists it as a class name +in the scope portion of the extension fields. Also, if a C++ function +is defined outside of the class declaration (the usual case), the access +specification (i.e. public, protected, or private) and implementation +information (e.g. virtual, pure virtual) contained in the function +declaration are not known when the tag is generated for the function +definition. It will, however be available for prototypes (e.g. --kinds-c++=+p).
+No qualified tags are generated for language objects inherited into a class.
+On Unix-like hosts where mkstemp(3) is available, the value of this +variable specifies the directory in which to place temporary files. +This can be useful if the size of a temporary file becomes too large +to fit on the partition holding the default temporary directory +defined at compilation time.
+ctags creates temporary +files only if either (1) an emacs-style tag file is being +generated, (2) the tag file is being sent to standard output, or +(3) the program was compiled to use an internal sort algorithm to sort +the tag files instead of the sort(1) utility of the operating system. +If the sort(1) utility of the operating system is being used, it will +generally observe this variable also.
+Note that if ctags +is setuid, the value of TMPDIR will be ignored.
+$XDG_CONFIG_HOME/ctags/*.ctags, or $HOME/.config/ctags/*.ctags if +$XDG_CONFIG_HOME is not defined +(on other than MS Windows)
+$HOME/.ctags.d/*.ctags
+$HOMEDRIVE$HOMEPATH/ctags.d/*.ctags (on MS Windows only)
+.ctags.d/*.ctags
+ctags.d/*.ctags
+++If any of these configuration files exist, each will be expected to +contain a set of default options which are read in the order listed +when ctags starts, but before any command line options +are read. This makes it possible to set up personal or project-level defaults.
+It +is possible to compile ctags to read an additional +configuration file before any of those shown above, which will be +indicated if the output produced by the --version option lists the +custom-conf feature.
+Options appearing on the command line will override options +specified in these files. Only options will be read from these +files.
+Note that the option +files are read in line-oriented mode in which spaces are significant +(since shell quoting is not possible) but spaces at the beginning +of a line are ignored. Each line of the file is read as +one command line parameter (as if it were quoted with single quotes). +Therefore, use new lines to indicate separate command-line arguments.
+A line starting with '#' is treated as a comment.
+*.ctags files in a directory are loaded in alphabetical order.
+
See ctags-optlib(7) for defining (or extending) a parser +in a configuration file.
+See tags(5) for the format of tag files.
+See ctags-incompatibilities(7) about known incompatible changes +with Exuberant Ctags.
+See ctags-client-tools(7) if you are interested in writing +a tool for processing tags files.
+See ctags-lang-python(7) about python input specific notes.
+See readtags(1) about a client tool for binary searching a +name in a sorted tags file.
+The official Universal Ctags web site at: https://ctags.io/
+Also ex(1), vi(1), elvis(1), or, better yet, vim(1), the official editor of ctags. +For more information on vim(1), see the Vim web site at: https://www.vim.org/
+Universal Ctags project +https://ctags.io/
+Darren Hiebert <dhiebert@users.sourceforge.net> +http://DarrenHiebert.com/
+"Think ye at all times of rendering some service to every member of the +human race."
+"All effort and exertion put forth by man from the fullness of his heart is +worship, if it is prompted by the highest motives and the will to do +service to humanity."
+-- From the Baha'i Writings
+This version of ctags (Universal Ctags) derived from +the repository, known as fishman-ctags, started by Reza Jelveh.
+The fishman-ctags was derived from Exuberant Ctags.
+Some parsers are taken from tagmanager of the Geany (https://www.geany.org/) +project.
+Exuberant Ctags was originally derived from and +inspired by the ctags program by Steve Kirkendall <kirkenda@cs.pdx.edu> +that comes with the Elvis vi clone (though virtually none of the original +code remains).
+Credit is also due Bram Moolenaar <Bram@vim.org>, the author of vim, +who has devoted so much of his time and energy both to developing the editor +as a service to others, and to helping the orphans of Uganda.
+The section entitled "HOW TO USE WITH GNU EMACS" was shamelessly stolen +from the info page for GNU etags.
+