blocks|key|1543089|text|ctags支持两个特性:允许您从函数调用跳转到它们的定义，以及全方位完成。第一个意味着当你结束对一个方法的调用时，点击g]或CTRL-]将跳转到定义或实现该方法的地方。第二个特性意味着，当您输入foo.或foo->时，如果foo是一个结构，那么将显示一个带有字段完成的弹出式菜单。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1543090|cscope也有第一个特性--使用set+cscopetag+--但没有最后一个。但是，cscope还添加了跳转到调用函数的任何位置的能力。|1543091|因此，就代码库而言，ctag只会将您带到实现函数的位置，而cscope也可以向您显示函数被调用的位置。|1543092|为什么你会选择一个而不是另一个呢？好吧，我两个都用。ctags更容易设置，运行速度更快，如果你只关心跳转一种方式，它会显示更少的行。你只需运行:!ctags+-R+.，g]就能正常工作。它还实现了全方位的功能。|1543093|Cscope非常适合更大的未知代码库。设置很麻烦，因为cscope需要一个包含要解析的文件名列表的文件。同样在vim中，默认情况下没有设置密钥绑定-您需要手动运行:cscope+blah+blah。|1543094|为了解决第一个问题，我有一个bash脚本cscope_gen.sh，如下所示：|1543095|#!/bin/sh
find+.+-name+'*.py'+\
-o+-name+'*.java'+\
-o+-iname+'*.[CH]'+\
-o+-name+'*.cpp'+\
-o+-name+'*.cc'+\
-o+-name+'*.hpp'++\
>+cscope.files

#+-b:+just+build
#+-q:+create+inverted+index
cscope+-b+-q|code-block|syntax|javascript|1543096|这将搜索我感兴趣的代码，创建cscope.files列表并创建数据库。这样我就可以运行":!cscope_gen.sh“，而不必记住所有的设置步骤。|1543097|我使用以下代码片段将cscope搜索映射到ctrl-space+x+2，这减轻了cscope的另一个缺点：|1543098|nmap+<C-@><C-@>+:cs+find+s+<C-R>=expand("<cword>")<CR><CR>|1543099|有一个this+cscope_maps.vim+plugin设置了一堆类似的绑定。我永远记不住所有选项的含义，所以倾向于使用ctrl-space。|1543100|所以总结一下:ctag更容易设置，而且大多数情况下不需要做太多的工作，它对omni-complete也是至关重要的。如果您必须维护一个大型且大多未知的代码库，cscope提供了更多的功能，但需要更多的分支工作。|1543101|entityMap|0|LINK|mutability|MUTABLE|url|http://cscope.sourceforge.net/cscope_maps.vim^0|1N|2|1Q|6|2P|4|2U|5|0|H|D|0|0|1Z|C|2C|2|0|29|H|0|K|D|0|0|0|0|0|3|R|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]|$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1O|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1P|8|@$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1X|8|@$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|R|7|20|8|@]|D|@]|E|$S|T]]|$1|U|3|V|5|6|7|21|8|@]|D|@]|E|$]]|$1|W|3|X|5|6|7|22|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|R|7|23|8|@]|D|@]|E|$S|T]]|$1|10|3|11|5|6|7|24|8|@]|D|@$9|25|A|26|1|27]]|E|$]]|$1|12|3|13|5|6|7|28|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|29|8|@]|D|@]|E|$]]]|15|$16|$5|17|18|19|E|$1A|1B]]]]

ctags enables two features: allowing you to jump from function calls to their definitions, and omni completion. The first means that when you are over a call to a method, hitting <code>g]</code> or <code>CTRL-]</code> will jump to the place where that method is defined or implemented. The second feature means that when you type <code>foo.</code> or <code>foo-&gt;</code>, and if foo is a structure, then a pop-up menu with field completion will be shown.

cscope also has the first feature - using <code>set cscopetag</code> - but not the last. However cscope additionally adds the ability to jump to any of the places where a function is called as well.

So as far as jumping around a code base is concerned, ctags will only ever lead you towards the place where the function is implemented, whereas cscope can show you where a function is called too.

Why would you choose one over the other? Well, I use both. ctags is easier to set up, faster to run and if you only care about jumping one way it will show you less lines. You can just run <code>:!ctags -R .</code> and <code>g]</code> just works. It also enables that omni complete thing.

Cscope is great for bigger, unknown code bases. The set up is a pain because cscope needs a file containing a list of names of files to parse. Also in vim, by default there are no key bindings set up - you need to run <code>:cscope blah blah</code> manually.

To solve the fist problem I've got a bash script <code>cscope_gen.sh</code> that looks like this:

<pre><code>#!/bin/sh
find . -name '*.py' \
-o -name '*.java' \
-o -iname '*.[CH]' \
-o -name '*.cpp' \
-o -name '*.cc' \
-o -name '*.hpp' \
&gt; cscope.files

# -b: just build
# -q: create inverted index
cscope -b -q
</code></pre>

This searches for code that I'm interested in, creates the cscope.files list and creates the database. That way I can run ":!cscope_gen.sh" instead of having to remember all the set up steps.

I map cscope search to ctrl-space x 2 with this snippet, which mitigates the other downer of cscope:

<pre><code>nmap &lt;C-@&gt;&lt;C-@&gt; :cs find s &lt;C-R&gt;=expand("&lt;cword&gt;")&lt;CR&gt;&lt;CR&gt;
</code></pre>

There's <a href="http://cscope.sourceforge.net/cscope_maps.vim" rel="noreferrer">this cscope_maps.vim plugin</a> that sets up a bunch of similar bindings. I can never remember what all the options mean, so tend to stick to ctrl-space.

So to conclude: ctags is easier to set up and mostly works without doing much else, it's vital for omni-complete too. cscope provides more features if you have to maintain a large and mostly unknown code base, but requires more leg work.

blocks|key|1543172|text|几个月前我也遇到过同样的情况...|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1543173|ctags的缺乏精确度是..中的一个问题，我发现cscope对于所有与宏相关的东西(+linux内核中有很多宏)来说要好得多。|1543174|关于用法，这实际上是straightforward...you，只要在内核的根目录下输入cscope+-R，就没什么可担心的了。(我的意思是，如果你只是想探索这是完美的……)|1543175|然后，键绑定都是基于Ctrl-\+(如果您对Ctrl敏感，可以重新映射它)，您主要使用s和g...，|1543176|为内核开发时，我不需要那么多的补全...|1543177|无论如何，使用cscope，这会更方便、更准确。|1543178|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

I was in the same situation some months ago...

The lack of precision of ctags is a pain in a.., and i find cscope much better for all the macros related stuff (and there are a bunch of macros in the linux kernel)..

concerning the usage, that's actually straightforward...you just type cscope -R at the root of your kernel and then you've got nothing to worry about.. (I mean if you just want to explore that's perfect...)

Then, the key bindings are all based on Ctrl-\ (you can remap it if you're allergic to Ctrl), you mainly use s and g....,

Developing for the kernel, I didn't need so much the completion....

Anyway, go for cscope, this is much more convenient, accurate.

blocks|key|1543242|text|建议使用全局gtag。可以使用vim插件gen_tags将gtags与vim集成。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1543243|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/jsfaint/gen_tags.vim^0|K|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Suggest use global gtags. Could use vim plugin <a href="https://github.com/jsfaint/gen_tags.vim" rel="nofollow noreferrer">gen_tags</a> to integrate gtags with vim.

I primarily use vim / gvim as an editor and am looking at using a combination of <a href="http://lxr.linux.no/" rel="noreferrer">lxr (the Linux Cross Reference)</a> and either <a href="http://cscope.sourceforge.net/" rel="noreferrer">cscope</a> or <a href="http://ctags.sourceforge.net/" rel="noreferrer">ctags</a> for exploring the kernel source. However, I haven't ever used either <a href="http://cscope.sourceforge.net/" rel="noreferrer">cscope</a> or <a href="http://ctags.sourceforge.net/" rel="noreferrer">ctags</a> and would like to hear why one might choose one over the other taking into consideration my use of vim as a primary editor.

cscope or ctags why choose one over the other?

数据库

我主要使用vim / gvim作为编辑器，并且正在考虑使用和或的组合来探索内核源代码。但是，我从来没有使用过或，我想知道考虑到我使用vim作为主编辑器，为什么它们可能会选择其中之一。

问cscope或ctag为什么选择一个而不是另一个？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问cscope或ctag为什么选择一个而不是另一个？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问cscope或ctag为什么选择一个而不是另一个？
EN