cscope ou ctags por que escolher um sobre o outro? [fechadas]

Eu uso principalmente o vim / gvim como editor e estou pensando em usar uma combinação de lxr (a referência cruzada do Linux) e cscope ou ctags para explorar a fonte do kernel. No entanto, nunca usei cscope ou ctags e gostaria de saber por que um pode escolher um sobre o outro, levando em consideração meu uso do vim como editor principal.

O ctags permite dois recursos: permitindo que você pule de chamadas de função para suas definições e omni-complete. O primeiro significa que, quando você realiza uma chamada para um método, acessa g]ou CTRL-]salta para o local em que esse método é definido ou implementado. O segundo recurso significa que, quando você digita foo.ou foo->, e se foo for uma estrutura, será exibido um menu pop-up com preenchimento de campo.

O cscope também possui o primeiro recurso - using set cscopetag- mas não o último. No entanto, o cscope também adiciona a capacidade de pular para qualquer um dos lugares onde uma função também é chamada.

Portanto, no que diz respeito a pular uma base de código, ctags sempre o levará ao local em que a função é implementada, enquanto o cscope também pode mostrar onde uma função é chamada.

Por que você escolheria um sobre o outro? Bem, eu uso os dois. O ctags é mais fácil de configurar, mais rápido de executar e se você se preocupa apenas em pular de uma maneira, isso mostra menos linhas. Você pode simplesmente correr :!ctags -R .e g]simplesmente funciona. Ele também permite essa coisa omni completa.

O Cscope é ótimo para bases de código maiores e desconhecidas. A configuração é um problema porque o cscope precisa de um arquivo que contém uma lista de nomes de arquivos para analisar. Também no vim, por padrão, não há ligações de teclas configuradas - você precisa executar :cscope blah blahmanualmente.

Para resolver o primeiro problema, eu tenho um script bash cscope_gen.shque se parece com isso:

#!/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

Isso procura pelo código do meu interesse, cria a lista cscope.files e cria o banco de dados. Dessa forma, eu posso executar ":! Cscope_gen.sh" em vez de ter que lembrar de todas as etapas de configuração.

Mapeio a pesquisa do cscope para ctrl-space x 2 com esse trecho, o que atenua o outro ponto negativo do cscope:

nmap <C-@><C-@> :cs find s <C-R>=expand("<cword>")<CR><CR>

Há esse plugin cscope_maps.vim que configura várias ligações semelhantes. Eu nunca consigo me lembrar do que todas as opções significam, por isso tende a manter o espaço no ctrl.

Então, para concluir: ctags é mais fácil de configurar e funciona principalmente sem fazer muito mais, é vital para o omni-complete também. O cscope fornece mais recursos se você precisar manter uma base de código grande e quase desconhecida, mas precisar de mais trabalho.

Eu estava na mesma situação há alguns meses ...

A falta de precisão das ctags é um problema em um .., e acho o cscope muito melhor para todas as coisas relacionadas a macros (e há várias macros no kernel do linux) ..

sobre o uso, isso é realmente simples ... você digita cscope -R na raiz do seu kernel e não precisa se preocupar com nada .. (quero dizer, se você quiser apenas explorar o que é perfeito ...)

Em seguida, as combinações de teclas são todas baseadas em Ctrl- \ (você pode remapear se for alérgico a Ctrl); você usa principalmente se eg ....,

Desenvolvendo para o kernel, eu não precisava tanto da conclusão ....

Enfim, vá para o cscope, isso é muito mais conveniente, preciso.

Hmm ... Você provavelmente deve usar etags em vez de ctags ...

Se você usa o cscope, pode ver cadeias de chamadas, ou seja, quem chama essa função e quais funções essa função chama?

Não tenho certeza se isso pode ser feito usando etags / ctags ...

Essa é apenas uma característica ... e descobrir o arquivo que contém uma definição de função específica? Isso você obtém apenas no cscope.

Eu uso tanto cscope e etags, ambos são bons para coisas diferentes, especialmente quando se trabalha com uma grande base de código, como o Kernel Linux. De fato, comecei a usar cscope e etags quando comecei a trabalhar com o Linux Kernel / Xen.

O LXR não é ótimo, porque você precisa clicar, acessar a rede etc., enquanto você pode criar os bancos de dados cscope e tags no código do kernel e não precisa acessar a rede (ao contrário do lxr).

Sugira usar gtags globais. Poderia usar o plugin vim gen_tags para integrar o gtags ao vim.