c++

emacs

vim

серьёзно?

По первому пункту ЛОР не пришел к единому мнению, по последнему - gtags, естественно, выиграет.

Но в том, что важно - в качестве индексации - gtags говно.

Ты не поверишь, но при мне типа который использует vim (без плагинья) для c++ кодирования пару раз звали в гугель, сначала в штаты потом в европы.

Так что дело не в бабине, просто говнокодец лучше с помощью тулов таки читать ;)

Дык интересует не коллективный разум, а отдельно взятые мнения.

А в чём выражается говёность индексации? Медленно или руками надо пускать?

А в чём выражается говёность индексации?

Символы не находит и путает: http://www.tamacom.com/tour/kernel/linux/

Ну, этим и rtags скорее всего страдает, покрайней мере qtc'шная надстройка над шлангом - грешит тем же, но не очень часто, даже не настолько что бы возникало хоть малейшее желание разбираться чего это оно.

Ну, этим и rtags скорее всего страдает

Вполне очевидно, что по ссылке ты не ходил.

ай, сорь, эт я только про emacs, vim-то в 11 стандарт умеет

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

ну дал он мне десяток референсов по имени первого попавшегося символа, ну qtc бывает так же делает

первого попавшегося

бывает

Окей.

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

Вполне возможно, тебе и gtags сойдет.

Gtags'u я готов многое простить т.к. оно есть в пакетах в попсовых осях. Но интересует собственно сравнение с rtags.

В rtags меня сильно прельщает понимание флагов компиляции и общий подход к архитектуре. Клиент сервер давно уже победил, но разработчики ide пока что тупят.

интересует собственно сравнение с rtags.

Найди демки Mozilla DXR или Woboq - увидишь, как индексируют Clang-based инструменты.

разработчики ide пока что тупят.

Каких IDE? В Eclipse вполне приличный индексатор, gtags даже сравнивать смешно. В QtCreator уже LLVM.

Я не про индексатор, а про подход. Бинарные интерфейсы вместо ipc. Один толстый вендорлок вместо юнихвейнинького разделяй и властвуй.

Эклипс то ладно, они уже думают в эту сторону(ссылку правда не нашёл чет сходу, проскакивала на лоре тема). Но тоже не совсем туда, им облака подавай, нет что бы начать с сетевой прозрачности.

Насмотрелись на студии визуальные понимаешь.

Я не про индексатор, а про подход.

Подход с библиотечным интерфейсом не отличается принципиально от подхода с северным интерфейсом.

Бинарные интерфейсы вместо ipc.

У libclang и clang_indexer вполне бинарные интерфейсы.

Один толстый вендорлок

Вендорлок на кого и почему он не помешал созданию eclim?

Впрочем, мы ушли от темы о собственно индексаторах.

Раз уж по теме всё равно никто ничё не пишет

Подход с библиотечным интерфейсом не отличается принципиально от подхода с северным интерфейсом.

Спорный вопрос. ipc даёт возможность взаимодействовать решениям написанным с использованием разных технологий и запущенных на разных машинах. Что есть в разы более масштабируемо и реюзабельно. Несомненно некоторые бинарные интерфейсы (c => c++, java, python,...) могут быть использованны проще чем другие (java => c, go).

У libclang и clang_indexer вполне бинарные интерфейсы

clang это в данном случае ассемблер, от него важнее производительность и уровень детализации.

А clang_indexer вместе с комплитом потому и почивают в лете (судя по датам на gh) что ycm тоже мало мало серверсайдный. Как и половина его бэкэндов, а вторая половина через менее продвинутый ipc гоняется, через пайпы там всякие.

Вендорлок на кого и почему он не помешал созданию eclim?

Вендорлок на конкретную ide и платформу. Может быть не совсем точное применения понятия в данном контексте, но лучше как то на ум не пришло.

Eclim требует установленного eclipse насколько я знаю, ну или художественного потрошения поделия. А теперь давай прикиним трудозатраты на написание eclimacs и eclime каких нить? Они будут ~= затратам на реализацию eclim как мне видится, хотя я с сабжем чуть менее чем не знаком, поэтому могу и ошибаться.

Хотя, я смотрю лорчане таки поддерживают ещё clang_complete.

clang_complete не нужен, есть youcompleteme.

Для работы с rtags вроде как проще всего использовать lyuts/vim-rtags.git, там насколько я помню нет биндингов в cscope, но есть к unite, что более-менее ок. В принципе должно быть довольно надежно, но пока ещё не везде применимо.

Для меня удобнее всего gtags-cscope. Бывает чудит, но терпимо, не парюсь, я обычно в таких случаях просто перехожу с помощью YcmCompleter.

Кстати использовать eclim тоже вполне себе здравая идея. Мне у эклипса gui не нравится прост, есть eclipse-che, который не компилируется и atom красивый, но ещё ничего не умеет(можно было бы его смешать с neovim+msgpack, но это немного «не то» было когда я в последний раз это пробовал), получается каша из биндингов если я не ошибаюсь. Ещё есть всякие продукты jetbrains, в которых вроде как всё ок и тормозит только гуй, но аналога eclim для них вроде как нет.

скорость работы на толстых кодовых базах

Ну ты сам подумай какая будет «скорость работы» от перекомпиляции.

Ну ты сам подумай какая будет «скорость работы» от перекомпиляции

Если перекомпиляция - инкрементальная,то почему бы и не быть скорости.

А используешь ты в итоге gtags? rtags попробовал? Чем gtags оказался удобней?

Если перекомпиляция - инкрементальная,то почему бы и не быть скорости.

Для некоторых проектов приходится делать make clean && make, что сводит инкрементальную компиляцию в ноль.

А используешь ты в итоге gtags?

Ога

rtags попробовал?

Пробовал, в том числе под emacs.

Чем gtags оказался удобней?

gtags-cscope из коробки. Так-то rtags пофичастее, просто мне не охота под него всё перенастраивать + ок поддержки vim'а нет, а деревья из хоткеев emacs я не особо люблю.

Ну, меня изкоробка тоже прельщает сильно.

Для некоторых проектов приходится делать make clean && make

Оффтоп, но можно пример, когда это необходимо?

У libclang и clang_indexer вполне бинарные интерфейсы

clang это в данном случае ассемблер

Индексатор Eclipse - тоже.

Вендорлок на кого и почему он не помешал созданию eclim?

Вендорлок на конкретную ide и платформу.

Не более, чем у rtags вендорлок на llvm.

Оффтоп, но можно пример, когда это необходимо?

С дивана не скажу, но на старой работе без этого шаманства проект мог не собираться. Естественно показать не могу, потому что сорцов у меня нет. Насколько я помню это довольно частая трабла, для этого отчасти полезен cmake, особенно если закрыть глаза на то что он генерит ад и Израиль. Может гугл чем поможет.

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

Индексатор eclipse можно ли использовать отдельно от эклипса, скажем в bash скрипте, без дополнительной кодовой обвязки?

А насколько сложно использовать его из c?

Ну я помню только один кейс, когда мне иногда, приходилось чистить проект, это было на комбинации Qt + mingw лет шесть назад, тогда qmake и/или mingw32-make подглючивал и не соображал что нужно что то пересобрать. Но возможно, это просто последствия моей не шибко высокой квалификации на тот момент.

Больше я такого не встречал, ну помимо багов в системах сборки которые после встречи дизентегрировались :)

Вообщем пробовать надо, эх я так надеялся что кто то однозначно скажет что gtags г-но, а rtags заруливает по самое нимогу, ну или наоборот.

Кстати тип, который пилит биндинг для rtags к vim'u делает очередной vimIde в котором использует и gtags и rtags, что найдётся вообщем.

Индексатор eclipse можно ли использовать отдельно от эклипса, скажем в bash скрипте, без дополнительной кодовой обвязки?

Нет.

А насколько сложно использовать его из c?

Примерно так же просто, как использовать libclang из Java.

Кстати тип, который пилит биндинг для rtags к vim'u делает очередной vimIde в котором использует и gtags и rtags, что найдётся вообщем.

Покажи.

Кстати наткнулся вот на такое чудо: https://github.com/JetBrains/hackathon-Embeditor/

Хм, круто, а как его установить? :D

Вот.

Хм, круто, а как его установить? :D

Что то мне подсказывает что кинуть в папочку (b|v)undle ;)

Ток для него идея нужна будет думаю.

Вообщем подытожу:

Решил потыкать сразу rtags. gtags пока не потыкал.

Очень понравился плагин и дефолтные биндинги.

Небольшой хинт: rtags - не собирается в многопоточном режиме make. По крайней мере сиё стабильно проявляется на fedora 22 и ubuntu 12.04. Долго скакал по релизным тегам, пока не дошло попробовать сделать make по умолчанию. Нинзя отрабатывает четко. Видимо регрессия в cmake или make.

Не понравилась сыроватость обоих поделий (самого rtags и плагина). Например, при любом действии над символом происходит рекомпиляция текущего файла и его зависимостей, что есть не допустимо. Работает сиё быстро, но процессором и диском шуршит постоянно, а самое главное впустую. Скорее всего косяк где то в алгоритме хэширования или в логике обработки «modified» файлов, в любом случае это минорщина.

Не понравилась архитектура rtags серевера на уровне кода и используемая в бэкэнде либа. Код написан неплохо, читается бодро, но архитектурно не додуманно (надеюсь wip), я ожидал увидеть что то вроде code model + rpc, а тут слегка иной уровень абстракции для клиента.

Вердикт - как он есть rtags очень хорош, хотя это и не то, чего лично я от него ожидал. Надо будет надосуге потыкать gtags сравнения для, но боюсь удобнее чем rtags любые системы основанные на тэгах будут врят ли :)

rtags топчег юзаю его с cmake-ide, irony, company и всеми бекендами возможными, лучше него пока ничего не нашел.