;"?
class::member?
;" which
follow many of the lines in the tag file?
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.
To fix this, add the following lines to your .emacs file, replacing the path to etags with the path where the symbolic link was installed.
(autoload 'speedbar "speedbar")
(setq speedbar-fetch-etags-command "/usr/local/bin/etags"
speedbar-fetch-etags-arguments '("-f" "-"))
--format=1 when running ctags to output the old tag file
format.
class::member?
--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.
.ctags file in your home
directory.
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 behaviour of Exuberant Ctags to behave
differently.
Standard Vi provides no facilities to alter this behavior. However, Vim has some nice features to minimize this problem, primarly 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.
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):
If you really insist on running ctags separately on each directory, you can
avoid the sort pass each time by specifying the option
ctags -R
--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.
http://people.delphiforums.com/gjc/gnu_regex.htmlThen point the makefile macro, REGEX_DIR, found in mk_mvc.mak and mk_bc5.mak, to the directory created by extracting this archive.
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.
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.
While Exuberant 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.
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.
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 currect 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:
Here is a recommended solution (conceptually) to build the tag files:
project
`-----misccomp
| `...
`-----sysint
`-----client
| `-----hdrs
| `-----lib
| `-----src
| `-----test
`-----common
| `-----hdrs
| `-----lib
| `-----src
| `-----test
`-----server
`-----hdrs
`-----lib
`-----src
`-----test
#!/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])&
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.
And replace the configuration of step 3 with this:
#!/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-
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:
:set tags=./tags,./../tags,./../../tags,./../../../tags,tags
cd ~/project
ctags --file-scope=no -R `pwd`