|
| 1 | +TAG FILE FORMAT |
| 2 | +=============== |
| 3 | + |
| 4 | +When not running in etags mode, each entry in the tag file consists of a |
| 5 | +separate line, each looking like this in the most general case:: |
| 6 | + |
| 7 | + tag_name<TAB>file_name<TAB>ex_cmd;"<TAB>extension_fields |
| 8 | + |
| 9 | +The fields and separators of these lines are specified as follows: |
| 10 | + |
| 11 | +#. Tag name |
| 12 | +#. Single tab character |
| 13 | +#. Name of the file in which the object associated with the tag is located |
| 14 | +#. Single tab character |
| 15 | +#. EX command used to locate the tag within the file; generally a search |
| 16 | + pattern (either ``/pattern/`` or ``?pattern?``) or line number (see |
| 17 | + ``−−excmd``). |
| 18 | + Tag file format 2 (see ``−−format``) extends this EX command under certain |
| 19 | + circumstances to include a set of extension fields (described below) |
| 20 | + embedded in an EX comment immediately appended to the EX command, which |
| 21 | + leaves it backward-compatible with original ``vi(1)`` implementations. |
| 22 | + |
| 23 | +A few special tags are written into the tag file for internal purposes. These |
| 24 | +tags are composed in such a way that they always sort to the top of the file. |
| 25 | +Therefore, the first two characters of these tags are used a magic number to |
| 26 | +detect a tag file for purposes of determining whether a valid tag file is |
| 27 | +being overwritten rather than a source file. Note that the name of each source |
| 28 | +file will be recorded in the tag file exactly as it appears on the command |
| 29 | +line. |
| 30 | + |
| 31 | +Therefore, if the path you specified on the command line was relative to the |
| 32 | +current directory, then it will be recorded in that same manner in the tag |
| 33 | +file. See, however, the ``−−tag−relative`` option for how this behavior can be |
| 34 | +modified. |
| 35 | + |
| 36 | +Extension fields are tab-separated key-value pairs appended to the end of the |
| 37 | +EX command as a comment, as described above. These key value pairs appear in |
| 38 | +the general form ``key:value``. Their presence in the lines of the tag file |
| 39 | +are controlled by the ``−−fields`` option. The possible keys and the meaning |
| 40 | +of their values are as follows: |
| 41 | + |
| 42 | +access |
| 43 | + Indicates the visibility of this class member, where value is specific to |
| 44 | + the language. |
| 45 | + |
| 46 | +file |
| 47 | + Indicates that the tag has file-limited visibility. This key has no |
| 48 | + corresponding value. |
| 49 | + |
| 50 | +kind |
| 51 | + Indicates the type, or kind, of tag. Its value is either one of the |
| 52 | + corresponding one-letter flags described under the various |
| 53 | + ``−−<LANG>−kinds`` options above, or a full name. It is permitted (and is, |
| 54 | + in fact, the default) for the key portion of this field to be omitted. The |
| 55 | + optional behaviors are controlled with the ``−−fields`` option. |
| 56 | + |
| 57 | +implementation |
| 58 | + When present, this indicates a limited implementation (abstract vs. concrete) |
| 59 | + of a routine or class, where value is specific to the language ("virtual" or |
| 60 | + "pure virtual" for C++; "abstract" for Java). |
| 61 | + |
| 62 | +inherits |
| 63 | + When present, value is a comma-separated list of classes from which this |
| 64 | + class is derived (i.e. inherits from). |
| 65 | + |
| 66 | +signature |
| 67 | + When present, value is a language-dependent representation of the |
| 68 | + signature of a routine. A routine signature in its complete form specifies |
| 69 | + the return type of a routine and its formal argument list. This extension |
| 70 | + field is presently supported only for C-based languages and does not |
| 71 | + include the return type. |
| 72 | + |
| 73 | +In addition, information on the scope of the tag definition may be available, |
| 74 | +with the key portion equal to some language-dependent construct name and its |
| 75 | +value the name declared for that construct in the program. This scope entry |
| 76 | +indicates the scope in which the tag was found. For example, a tag generated |
| 77 | +for a C structure member would have a scope looking like ``struct:myStruct``. |
0 commit comments