22439 файлов! Жесть какая.
Да, надо что-то менять в алгоритме :) Я, когда писал плагин, по неопытности не рассчитывал, что им будут индексировать такие огромные проекты.
А IndexerInfo возвращает кол-во найденных им файлов, которые он скормил ctags'у, а успешно ли все проиндексировалось, не проверяет.
Пожалуй, нужно сделать, чтобы в случае использования indexer_files, а не .vimprojects, ctags'у передавались не файлы, а папки проекта, и с ключом -R.
Насчет падения indexer: похоже, мне придется скачать исходники Qt и подебажить, потому что так мало что ясно. Однако я бы посоветовал убрать ключ -R из опций ctags, т.к. он тут бесполезен: в команде ctags перечисляются все найденные индексером файлы, а не директория проекта. Попробуйте, пожалуйста: может и ошибок тогда не будет, хотя вряд ли…
Насчет второго бага: правда ваша, самый что ни на есть баг. Спасибо, скоро поправлю.
В нижней части скриншота — окно quickfix.
Очень удобен для быстрой навигации по коду (по ошибкам компиляции или, например, по результатам поиска grep или vimgrep). Можно почитать о нем в этой статье, ну и, конечно же, :help quickfix.
Ну а плагин project позволяет это дело еще больше автоматизировать: в окне плагина нажимаем <Leader>g (Если не знаете, что такое <Leader>, значит, вам нужно нажимать \g и почитать :help leader на досуге), вводим регулярку — наблюдаем результат поиска по всем файлам проекта (или подпроекта — в зависимости от того, в какой ветке проекта находился курсор).
На скриншоте в окне quickfix находятся как раз результаты поиска.
Честно говоря, я писал с оглядкой на подобные статьи на самом Хабре. Взять хотя бы эту: vim, и как сделать из него полноценную IDE. Хотя в статье нет ничего из перечисленного вами, нет управления проектами, нет индексации файлов. Так что я решил, что моя реализация «IDE» даже более «IDEшная», чем в других просмотренных мною статьях, и не постеснялся употребить этот термин.
предложенный indexer_files будет считать одним проектом только директорию ~/workspace/myproject со всеми поддиректориями рекурсивно.
Допустим, у вас есть еще один проект, и лежит он в папке "~/workspace/my_second_project". Тогда нужно отредактировать файл ~/.indexer_files следующим образом:
[myProject]
~/workspace/myproject**/*
[myProject2]
~/workspace/my_second_project**/*
теперь, когда вы откроете в Vim любой файл из директории ~/workspace/myproject (или любой поддиректории), то будут проиндексированы все файлы, находящиеся в ~/workspace/myproject и всех поддиректориях. А те файлы, которые лежат в ~/workspace/my_second_project, проиндексированы не будут, т.к. это другой проект.
т.е. для каждого проекта вам нужно в indexer_files создать секцию (в квадратных скобках), а ниже перечислить по аналогии с примером все директории, входящие в проект.
а вот насчет того, что поиск папки .vim будет находить "~/.vim"… Знаете, похоже, я ступил. Пожалуй, нужно изменить название по умолчанию с ".vim" на какой-нибудь ".vim_indexer"
Спасибо за code_complete (new update), посмотрю.
А вообще, code_complete это для меня временный вариант, т.к. мне больше нравится не подстановка параметров, а следующий вариант: вот я пишу «имя_функции(», и как только открываю скобку, появляется popup-окошко с перечислением аргументов функции, а текущий аргумент как-то выделен и снизу отображается комментарий для него (то есть надо будет сделать, например, парсинг комментариев по стандарту javadoc). Когда я указал один аргумент и поставил запятую, выделяется следующий аргумент и отображается комментарий для него. Ну, и т.д.
Ну и перегрузки метода можно менять стрелками вверх/вниз.
Такого плагина я тоже не нашел, так что в скором времени займусь.
вот список возможностей, появляющихся после установки плагинов, так или иначе описанных в статье:
* управление проектами и файлами, входящими в состав проектов (project)
* автоматическая индексация всех файлов проекта (indexer)
* отображение элементов структур, классов, проч. (omnicppcomplete)
* автодополнение аргументов функций (code_complete)
Чего не хватает для использования в качестве среды разработки?
ну, разумеется, не понадобится. Упомянули бы тогда еще и то, что мой плагин не понадобится для использования omnicppcomplete и code_complete — они ведь также работают с ctags.
Я просто сразу рассказал об одной из ключевых возможностей, появляющейся при использовании тегов. Рассказал для людей, которые вообще не имели дела с ctags. Или это неправильно?
Добавить-то несложно, но уточню: а если вам нужно отредактировать какой-нибудь отдельный файл, например, где-нибудь в /etc? Vim должен будет искать файлы-исходники в /etc и всех подпапках?
Или, допустим, на подключенной удаленной директории с помощью sshfs? — тогда пользователь устанет ждать, пока будет проходить индексация удаленной ФС.
Или нужно сделать какую-нибудь команду, которую надо будет вводить каждый раз при открытии Vim для работы над проектом? (ну или клавишу замапить, и нажимать эту клавишу)
По-моему все-таки лучше отключить поиск папки ".vim", добавив следующую строку в _vimrc:
let g:indexer_lookForProjectDir = 0
и создать файл ~/.indexer_files следующего содержания:
Файл тегов для разных проектов будут называться по-разному.
А чтобы ctags запускался с ключом -R для всей директории проекта, добавьте в .vimrc
let g:indexer_ctagsDontSpecifyFilesIfPossible = 1
Минус этого варианта в том, что тогда indexer не будет сам сканировать дерево проекта и в переменной &path будет только корневая папка проекта.
Да, надо что-то менять в алгоритме :) Я, когда писал плагин, по неопытности не рассчитывал, что им будут индексировать такие огромные проекты.
А IndexerInfo возвращает кол-во найденных им файлов, которые он скормил ctags'у, а успешно ли все проиндексировалось, не проверяет.
Пожалуй, нужно сделать, чтобы в случае использования indexer_files, а не .vimprojects, ctags'у передавались не файлы, а папки проекта, и с ключом -R.
Насчет второго бага: правда ваша, самый что ни на есть баг. Спасибо, скоро поправлю.
[PROJECTS_PARENT filter="*.c *.h *.cpp"]~/workspace
Это должно вам помочь :)
Очень удобен для быстрой навигации по коду (по ошибкам компиляции или, например, по результатам поиска grep или vimgrep). Можно почитать о нем в этой статье, ну и, конечно же, :help quickfix.
Ну а плагин project позволяет это дело еще больше автоматизировать: в окне плагина нажимаем <Leader>g (Если не знаете, что такое <Leader>, значит, вам нужно нажимать \g и почитать :help leader на досуге), вводим регулярку — наблюдаем результат поиска по всем файлам проекта (или подпроекта — в зависимости от того, в какой ветке проекта находился курсор).
На скриншоте в окне quickfix находятся как раз результаты поиска.
.vimrc — держи.
[global]projects_dir=~/workspace/
Честно говоря, я писал с оглядкой на подобные статьи на самом Хабре. Взять хотя бы эту: vim, и как сделать из него полноценную IDE. Хотя в статье нет ничего из перечисленного вами, нет управления проектами, нет индексации файлов. Так что я решил, что моя реализация «IDE» даже более «IDEшная», чем в других просмотренных мною статьях, и не постеснялся употребить этот термин.
Если вы настаиваете, уберу :)
Допустим, у вас есть еще один проект, и лежит он в папке "~/workspace/my_second_project". Тогда нужно отредактировать файл ~/.indexer_files следующим образом:
[myProject]
~/workspace/myproject**/*
[myProject2]
~/workspace/my_second_project**/*
теперь, когда вы откроете в Vim любой файл из директории ~/workspace/myproject (или любой поддиректории), то будут проиндексированы все файлы, находящиеся в ~/workspace/myproject и всех поддиректориях. А те файлы, которые лежат в ~/workspace/my_second_project, проиндексированы не будут, т.к. это другой проект.
т.е. для каждого проекта вам нужно в indexer_files создать секцию (в квадратных скобках), а ниже перечислить по аналогии с примером все директории, входящие в проект.
А вообще, code_complete это для меня временный вариант, т.к. мне больше нравится не подстановка параметров, а следующий вариант: вот я пишу «имя_функции(», и как только открываю скобку, появляется popup-окошко с перечислением аргументов функции, а текущий аргумент как-то выделен и снизу отображается комментарий для него (то есть надо будет сделать, например, парсинг комментариев по стандарту javadoc). Когда я указал один аргумент и поставил запятую, выделяется следующий аргумент и отображается комментарий для него. Ну, и т.д.
Ну и перегрузки метода можно менять стрелками вверх/вниз.
Такого плагина я тоже не нашел, так что в скором времени займусь.
вот список возможностей, появляющихся после установки плагинов, так или иначе описанных в статье:
* управление проектами и файлами, входящими в состав проектов (project)
* автоматическая индексация всех файлов проекта (indexer)
* отображение элементов структур, классов, проч. (omnicppcomplete)
* автодополнение аргументов функций (code_complete)
Чего не хватает для использования в качестве среды разработки?
ну, разумеется, не понадобится. Упомянули бы тогда еще и то, что мой плагин не понадобится для использования omnicppcomplete и code_complete — они ведь также работают с ctags.
Я просто сразу рассказал об одной из ключевых возможностей, появляющейся при использовании тегов. Рассказал для людей, которые вообще не имели дела с ctags. Или это неправильно?
Или, допустим, на подключенной удаленной директории с помощью sshfs? — тогда пользователь устанет ждать, пока будет проходить индексация удаленной ФС.
Или нужно сделать какую-нибудь команду, которую надо будет вводить каждый раз при открытии Vim для работы над проектом? (ну или клавишу замапить, и нажимать эту клавишу)
По-моему все-таки лучше отключить поиск папки ".vim", добавив следующую строку в _vimrc:
let g:indexer_lookForProjectDir = 0и создать файл ~/.indexer_files следующего содержания:
[myProject]~/workspace/myproject**/*