Каковы самые простые / лучшие методы управления файлами тегов ctags?

Я только начал использовать ctags и очень ценю этот инструмент, но способ управления файлом тегов, на мой взгляд, несколько громоздкий и очень негибкий.

Как я сейчас управляю своим файлом тегов:

  1. У меня есть один монолитный файл тегов, который хранится в моей домашней папке по адресу ~/.vim/tags
  2. Когда я обновляю свой код или меняю проекты, я запускаю сценарий, который удаляет старый файл тегов и восстанавливает монолитный файл тегов (вы должны изменить место, где ctags запускается, когда вы меняете проекты)

Мне подходит один монолитный файл тегов, потому что он позволяет мне переходить ко всем соответствующим символам для текущего проекта, над которым я работаю.

Разве один монолитный файл тегов не будет работать для большой / огромной кодовой базы? Почему огромный файл тегов не работает с большой / огромной кодовой базой?

Как еще можно управлять файлом тегов (или файлами тегов во множественном числе)?

И почему ваш новый метод управления файлами тегов должен быть лучше? (По-видимому, лучшее решение иногда может быть более сложным. Поэтому, если ваше решение более сложное, я спрашиваю вас, какие дополнительные преимущества дает более сложный метод управления файлами тегов.)

p.s. Я нашел вопрос stackoverflow, в котором говорится о ctags под названием «vimctags-tips-and-tricks», но это вопрос не говорит о том, как управлять вашими файлами тегов.


development-environment vim ctags
person Trevor Boyd Smith    schedule 10.08.2009    source источник

Ответы (4)


arrow_upward
7
arrow_downward

Я поместил свой tags файл в каталог проекта. Это позволяет хранить теги отдельно для каждого проекта.

Для больших кодовых баз я просто уменьшаю частоту, с которой я их обновляю. Обычно я обновляю его, только если пытаюсь перейти к ключевому слову, а его по какой-то причине нет. В конце концов, цель состоит в том, чтобы быстро добраться до какой-либо другой части кода, и если он попадает туда каким-либо образом, то он работает, даже если файл тега устарел.

person Greg Hewgill    schedule 10.08.2009
comment
+1 на подходе. Я также использую cscope - и у меня есть трехстрочный сценарий оболочки, который воссоздает файлы для обоих, когда они становятся устаревшими. - person Andrew Y; 10.08.2009

arrow_upward
10
arrow_downward

Один из подходов, который мне недавно понравился, - это использование хуков VCS (системы контроля версий) для генерации файлов ctags. Я использую git локально даже для небольших проектов и тому подобного, поэтому ctags обновляется каждый раз, когда я фиксирую (это, очевидно, возможно со всеми другими VCS).

Мне лично нравится помещать файл ctags в каталог каждого проекта, но этот подход должен работать так же хорошо во всем мире.

РЕДАКТИРОВАТЬ: перехватчики VCS - это сценарии или программы, которые запускаются автоматически при выполнении определенных действий, таких как извлечение, фиксация, возврат и другие.
Для дальнейшего чтения я предлагаю следующие ссылки:

Хуки обычно доступны во всех VCS, с которыми я столкнулся, и я уверен, что вы сможете найти документацию для той, которую вы выбрали для использования.

person drrlvn    schedule 11.08.2009
comment
Я не знаю, что такое хуки VCS. Может быть, вы могли бы подробнее рассказать о хуках VCS и о том, как он знает, что теги нужно восстанавливать при фиксации? - person Trevor Boyd Smith; 11.08.2009
comment
Я обновил ответ и надеюсь, что теперь он дает больше информации. Буду рад дать дополнительные разъяснения при необходимости. - person drrlvn; 13.08.2009
comment
хуки на стороне клиента или на стороне сервера? Я думаю, что клиентская сторона лучше подходит для того, что вы хотите делать, но Subversion не работает на стороне клиента. - person Craig McQueen; 27.10.2009

arrow_upward
1
arrow_downward

Как и Грег, я храню файл тегов в каталоге проекта. Затем я использую плагин project с его тегом in= для настройки тега расположение файла и необходимость использования рекурсии при регенерации tags и cscope.out для разных проектов.

Обычно я обновляю файл тегов только тогда, когда произошли значительные изменения, поскольку тег обычно приводит вас к нужной строке (или, по крайней мере, почти к правой строке), даже если он устарел. Основная причина, по которой я обновляю, заключается в том, что я добавил новое перечисление, структуру или подобное и хочу, чтобы подсветка синтаксиса тега, которую необходимо обновить.

person DrAl    schedule 11.08.2009

arrow_upward
0
arrow_downward

За исключением плагинов vim, для которых у меня есть только один файл тегов, у меня также есть одна база данных ctags для каждого проекта.

Это подразумевает две вещи:

  1. способ обнаружения «проектов» и соответствующей настройки vim. Для этого существует множество подключаемых модулей.
  2. способ иметь разные настройки для разных проектов одновременно. Вот где setlocal tags=... (/ setlocal tags+=) играет свою роль.

В большинстве случаев у проектов нет общих тегов. Как следствие, я доволен обнаружением текущего проекта, чтобы автоматически определять, где я обновляю теги и где я их читаю. Это два разных варианта использования, и vim обрабатывает (изначально) только последний. Плагины, которые обрабатывают первый вариант использования, должны указывать (локальную буферную) переменную для хранения информации.

Фактически, при сохранении файла должна обновляться только одна конкретная база данных тегов, нам может потребоваться получить теги для нескольких баз одновременно. Это вариант использования, который у меня есть, когда я работаю над библиотеками / проектами, которые зависят друг от друга: мне часто нужно что-то проверить в (~ стороннем) коде, который я импортирую. Я мог бы использовать глобальные &tags параметры, но я решил (пока) иметь разные значения в разных буферах. Еще раз, об этом варианте использования позаботились благодаря плагину local-vimrc, который я использую.

Что касается обновления базы данных тегов, это делается с помощью плагина (который я поддерживаю, но там существуют другие с аналогичными возможностями): я удаляю теги, связанные с текущим файлом, из связанной базы данных тегов проекта, затем обновляю с помощью параметра -a в фоновом режиме. На самом деле нет необходимости анализировать весь проект каждый раз, когда мы сохраняем файл.

В случае, если файлы проекта обновляются за пределами vim, у меня все еще есть возможность запускать теги для всего проекта. Хотя с крючками фиксации все прозрачно, я могу обновить словарь проверки орфографии vim, чтобы не отмечать идентификаторы кода как слова с ошибками. Я подозреваю, что с чистым подходом с фиксацией фиксации было бы немного утомительнее.

person Luc Hermitte    schedule 14.08.2017