- 浏览: 563133 次
- 性别:
- 来自: 上海
文章分类
- 全部博客 (233)
- CSS (12)
- J2SE学习 (16)
- J2EE (6)
- JavaScript (38)
- Struts 1.x (2)
- SQL (9)
- Hibernate (5)
- TYPO3 (1)
- Mysql (10)
- Drupal (14)
- 生活 (10)
- PHP (40)
- Linux (15)
- 口语 (2)
- Magento (8)
- Dotnet (2)
- 正则 (2)
- Android ADB shell (1)
- Android (7)
- HTTP (4)
- Android API (2)
- eclipse (1)
- JAVA (4)
- 数据结构 (3)
- 集合 (1)
- IoC(反向控制) (2)
- 设计模式 (3)
- WebView (2)
- 算法 (6)
- smsniff (1)
- VIM (7)
- iOS (4)
- gcc (2)
- xcode (1)
- Mac (5)
- opencv (3)
- cmake (2)
- git (1)
- html5 (1)
- audio (1)
- apache (3)
- shell (1)
- 工作感悟 (1)
最新评论
-
jiyilee:
的确,不少命令都不能用,不方便啊。。
Apple:如何在iphone、ipad上安装一些常用命令行命令 -
idong杨:
[url][url][url][url][url][/url] ...
php中将SimpleXMLElement Object数组转化为普通数组 -
idong杨:
...
php中将SimpleXMLElement Object数组转化为普通数组 -
wcily123:
递归删除指定目录下的.git文件find . -name .g ...
Linux上批量删除.svn目录 -
yilinsitian:
受教了,好像Socket通信超时机制 还没有说吧
Android·HTTP超时机制
收藏一下 有时间研究一下~
Frequently Asked Questions
==========================
* 1. Why do you call it "Exuberant Ctags"?
* 2. Why doesn't my editor work with these tag files?
* 3. What are these strange bits of text beginning with ;"?
* 4. Why doesn't XEmacs' Speedbar module work with Exuberant Ctags?
* 5. Why doesn't Xemacs correctly locate the tag in the source file?
* 6. Why doesn't NEdit correctly locate the tag in the source file?
* 7. Why can't I jump to "class::member"?
* 8. How can I avoid having to specify my favorite option every time?
* 9. Why do I end up on the wrong line when I jump to a tag?
* 10. How do I jump to the tag I want instead of the wrong one by the
same name?
* 11. What is "Vim"?
* 12. How can I locate all references to a specific function or variable?
* 13. Why does appending tags to a tag file tag so long?
* 14. How do I get regex support for Win32?
* 15. How should I set up tag files for a multi-level directory hierarchy?
----------------------------------------------------------------------
1. Why do you call it "Exuberant Ctags"?
Because one of the meanings of the word "exuberant" is:
exuberant : produced in extreme abundance : PLENTIFUL syn see PROFUSE
Compare the tag file produced by Exuberant Ctags with that produced by any
other ctags and you will see how appropriate the name is.
----------------------------------------------------------------------
2. Why doesn't my editor work with these tag files?
3. 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.
----------------------------------------------------------------------
4. Why doesn't XEmacs' Speedbar module work with Exuberant Ctags?
The default command line switches used by XEmacs for "etags" are not
compatible with Exuberant Ctags options. By default, Exuberant Ctags installs
a symbolic link, "etags", pointing to the ctags executable. When Exuberant
Ctags is started with the name "etags", it produces Emacs-style tag files by
default.
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" "-"))
----------------------------------------------------------------------
5. Why doesn't Xemacs correctly locate the tag in the source file?
This has been observed with version 20.3. It seems that when Xemacs searches
for a tag, it searches using the tag name instead of the search string located
in the TAGS file. This is a bug in Xemacs and does not occur in the GNU
version of Emacs.
----------------------------------------------------------------------
6. Why doesn't NEdit correctly locate the tag in the source file?
Versions of NEdit prior to 5.1 did not support the extended tag file format
generated by Exuberant Ctags by default. Either upgrade to version 5.1 or
specify the option "--format=1" when running ctags to output the old tag file
format.
----------------------------------------------------------------------
7. 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.
----------------------------------------------------------------------
8. 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 file in your home directory.
----------------------------------------------------------------------
9. 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
behaviour of Exuberant Ctags to behave differently.
----------------------------------------------------------------------
10. 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, 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.
----------------------------------------------------------------------
11. What is "Vim"?
Vim is a vi-compatible editor available as source and compilable for any
platform. Yeah, I know the first reaction is to shy away from this. But you
will never regret getting it, and you will become greatly attached to its
features, which you can learn gradually. I would be willing to say that it
is the best vi-clone available within 4 light-years of Alpha Centauri. It
works (nearly) exactly like standard vi, but provides some incredibly useful
extensions (some of which I have participated in designing with the author).
Most Linux distributions have adopted Vim as its standard vi.
----------------------------------------------------------------------
12. 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
----------------------------------------------------------------------
13. 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.
----------------------------------------------------------------------
14. How do I get regex support for Win32?
You need to download the GNU regex package for Win32 from the following
location:
http://people.delphiforums.com/gjc/gnu_regex.html
Then point the makefile macro, REGEX_DIR, found in mk_mvc.mak and mk_bc5.mak,
to the directory created by extracting this archive.
----------------------------------------------------------------------
15. 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 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.
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 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:
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,./../tags,./../../tags,./../../../tags,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`
--
Frequently Asked Questions
==========================
* 1. Why do you call it "Exuberant Ctags"?
* 2. Why doesn't my editor work with these tag files?
* 3. What are these strange bits of text beginning with ;"?
* 4. Why doesn't XEmacs' Speedbar module work with Exuberant Ctags?
* 5. Why doesn't Xemacs correctly locate the tag in the source file?
* 6. Why doesn't NEdit correctly locate the tag in the source file?
* 7. Why can't I jump to "class::member"?
* 8. How can I avoid having to specify my favorite option every time?
* 9. Why do I end up on the wrong line when I jump to a tag?
* 10. How do I jump to the tag I want instead of the wrong one by the
same name?
* 11. What is "Vim"?
* 12. How can I locate all references to a specific function or variable?
* 13. Why does appending tags to a tag file tag so long?
* 14. How do I get regex support for Win32?
* 15. How should I set up tag files for a multi-level directory hierarchy?
----------------------------------------------------------------------
1. Why do you call it "Exuberant Ctags"?
Because one of the meanings of the word "exuberant" is:
exuberant : produced in extreme abundance : PLENTIFUL syn see PROFUSE
Compare the tag file produced by Exuberant Ctags with that produced by any
other ctags and you will see how appropriate the name is.
----------------------------------------------------------------------
2. Why doesn't my editor work with these tag files?
3. 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.
----------------------------------------------------------------------
4. Why doesn't XEmacs' Speedbar module work with Exuberant Ctags?
The default command line switches used by XEmacs for "etags" are not
compatible with Exuberant Ctags options. By default, Exuberant Ctags installs
a symbolic link, "etags", pointing to the ctags executable. When Exuberant
Ctags is started with the name "etags", it produces Emacs-style tag files by
default.
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" "-"))
----------------------------------------------------------------------
5. Why doesn't Xemacs correctly locate the tag in the source file?
This has been observed with version 20.3. It seems that when Xemacs searches
for a tag, it searches using the tag name instead of the search string located
in the TAGS file. This is a bug in Xemacs and does not occur in the GNU
version of Emacs.
----------------------------------------------------------------------
6. Why doesn't NEdit correctly locate the tag in the source file?
Versions of NEdit prior to 5.1 did not support the extended tag file format
generated by Exuberant Ctags by default. Either upgrade to version 5.1 or
specify the option "--format=1" when running ctags to output the old tag file
format.
----------------------------------------------------------------------
7. 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.
----------------------------------------------------------------------
8. 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 file in your home directory.
----------------------------------------------------------------------
9. 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
behaviour of Exuberant Ctags to behave differently.
----------------------------------------------------------------------
10. 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, 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.
----------------------------------------------------------------------
11. What is "Vim"?
Vim is a vi-compatible editor available as source and compilable for any
platform. Yeah, I know the first reaction is to shy away from this. But you
will never regret getting it, and you will become greatly attached to its
features, which you can learn gradually. I would be willing to say that it
is the best vi-clone available within 4 light-years of Alpha Centauri. It
works (nearly) exactly like standard vi, but provides some incredibly useful
extensions (some of which I have participated in designing with the author).
Most Linux distributions have adopted Vim as its standard vi.
----------------------------------------------------------------------
12. 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
----------------------------------------------------------------------
13. 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.
----------------------------------------------------------------------
14. How do I get regex support for Win32?
You need to download the GNU regex package for Win32 from the following
location:
http://people.delphiforums.com/gjc/gnu_regex.html
Then point the makefile macro, REGEX_DIR, found in mk_mvc.mak and mk_bc5.mak,
to the directory created by extracting this archive.
----------------------------------------------------------------------
15. 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 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.
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 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:
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,./../tags,./../../tags,./../../../tags,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`
--
发表评论
-
删除VIM中 ^M
2015-04-08 08:10 408:%s/<Ctrl-V><Ctrl-M&g ... -
Vim的snipMate插件
2012-08-28 10:59 3096Vim的snipMate插件 介绍 终于发现了一个插件,对于 ... -
vim显示换行符
2012-06-09 15:50 5082vim显示换行符 set list 就是 Tab 的地方会 ... -
vim中翻页的命令
2012-06-07 15:27 1252vim中翻页的命令 整页翻页 ctrl-f ctrl-b f ... -
vim lookupfile插件tagfile 生成
2012-06-04 09:29 2309<?php /** 命令 :l ... -
VIM复制粘贴大全!
2012-05-28 10:57 4040VIM复制粘贴大全! 原 ...
相关推荐
Vim 是一款强大的文本编辑器,它以其高度可配置性和高效的工作流深受程序员和开发者喜爱。在Vim中,插件是扩展其功能的关键,"ctags" 和 "taglist" 就是两个非常实用的插件,尤其对于代码浏览和导航来说。...
"Atom-ctags,扩展的规则以支持强大的ctag中的现代perl.zip" 这个标题提到了两个关键概念,一个是"Atom-ctags",另一个是"现代perl"。Atom-ctags显然是Atom编辑器的一个插件,它的主要功能是增强ctags工具对Perl编程...
Linux源代码阅读是每个开发人员必备的技能,尤其是在面对庞大的Linux内核时。Vim、ctags和cscope是Linux开发人员常用的代码阅读工具,它们能够帮助开发者更高效地理解和导航源代码。以下是对这些工具的详细介绍: ...
ultraEdit的Ctag标签工具的实现源代码,用来阅读学习tag管理有借鉴意义
标题中的"ctag.rar_ctag%2_ctags_sourcecookifier"可能是指`ctags`在Windows环境下的版本,其中`%2`可能是URL编码后的空格。在Windows下,用户可以通过下载`.rar`压缩包进行解压安装,通常包含可执行文件`ctags.exe`...
代码阅读,vim插件使用,根据自己指定的目录生成ctags cscope等索引文件,shell脚本,仅供参考。
其次,`ctag`是一种用于创建和使用标签的工具。在Vim中,ctags生成的标签文件允许用户通过按`Ctrl+]`快速跳转到函数或变量的定义处,反之,通过`Ctrl+T`可以返回原来的位置。这对于多文件的大型项目尤其有用,使得...
"vim配置+ctag像source insight一样方便阅读代码"这个主题旨在让Vim拥有类似Source Insight的代码导航能力。 Source Insight是一款流行的源代码查看和编辑工具,以其强大的代码跳转、搜索和分析功能著称。要在Vim中...
在中提供CTags Support的扩展! ext install ctags-support 附加设置 使用此扩展名之前,您必须安装并生成.tags文件。 在您的项目文件夹下运行CTags命令。 ctags -R -f .tags 键绑定 1.导航到定义 ...
CTAGSträmpler 这个软件库包含固件和hardwaredesigns(反恐怖主义行动小组和 Strämpler的)。 !! 新! Strämpler现在可以运行作为替代固件! 包含在/ bin文件夹中! 这是什么: 半流光,半采样器,因此被称为...
在windows下用vim的兄弟不少吧。 代码的话需要用cscope和ctags的组合, 可以达到类似sourceinsight的效果。这次上传的是cscope.exe和ctags.exe。这个是编译好的版本,在windows下直接用。不需要cygwin.dll的参与 我...
CustomTags This applications clearly inplements custom tag and it use in jsp pages. And is very useful while developing jsp applications.
在Linux环境中,Vim是一个非常强大的文本编辑器,深受程序员喜爱。它的高度可定制性和高效操作方式使得熟练掌握Vim成为提升开发效率的关键。而`ctags`和`cscope`则是Vim中的两个强大工具,能够帮助程序员快速跳转...
**ctags工具详解** `ctags`是一款强大的源代码索引工具,主要用于在大型项目中快速定位函数、类、变量等编程元素。它通过扫描源代码文件,生成一个索引文件(如`.tags`),使得开发者能通过编辑器或终端快速跳转到...
- `CFG-VOIPSERVICE::OLTID=172.17.254.172,PONID=1-1-6-8,ONUIDTYPE=SN,ONUID=ZTEG7201931A,ONUPORT=1-1-1-1:CTAG::PT=H.248,TID=A1,VOIPVLAN=3304,IPMODE=static,IP=10.103.61.158,IPMASK=255.255.255.224,IP...
在IT行业中,编辑器是程序员日常工作中不可或缺的工具,Vim作为一款强大的文本编辑器,因其高度可定制性而备受青睐。"vim + ctags + cscope + nerdtree + taglist + vundle"的组合,是Vim高效开发环境的经典搭建方案...
Sublime Text 3是一款广受开发者喜爱的轻量级、高度可定制的代码编辑器,以其优秀的性能和丰富的插件支持而闻名。它不仅适用于多种编程语言,而且提供了丰富的代码高亮、自动完成、多选编辑等特性,极大地提升了开发...
NULL 博文链接:https://o396032767.iteye.com/blog/2255895
TU Delft学生在T. Abeel的指导下制造的基因组种群图可视化仪 入门 首先,请先存储库中标记的一个JAR。 最好采用最新构建的JAR。 要启动该应用程序,只需双击下载的JAR。 如果这不能启动您的应用程序,则可能意味着您...
您必须在项目中指定许多环境变量,所有环境变量都以CT_开头(对于CTag): CT_PROJECT_ROOT-项目的根目录。 CT_PROJECT_INCLUDE-其他项目的根目录,用于从中搜索其他标记文件(以冒号分隔)。 您还可以设置一些可...