Я не говорил, что не решаемя, просто смысла не имеет учитываюя трудозатраты

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

которая завалится на первом сложном выражении с шаблонами или перегруженной функции

Зачем это парсить для составления дерева объявлений? Анализ наследования в задачи дерева не входит.

Если объективно, то кроме жирного установщика остальное это 4.2. Хотя сам тоже недолюбливаю эту среду и её вендора.

Как там в 2017ом и 2006ом? В наши дни темки типа ctags нужны только для огромных read-only проектов типа ядрышка и хромиум.

Rtags - опередили время, это был один из первых подходов к решениям типа LSP, наверное где-то рядом был только YCM.

Не удивлюсь, если monodevelop это делает.

Как там в 2017ом и 2006ом? В наши дни темки типа ctags нужны только для огромных read-only проектов типа ядрышка и хромиум.

Для Си я так и использую - для внешних проектов, удобно разбираться в коде, больше там ничего и не надо.

Rtags - опередили время, это был один из первых подходов к решениям типа LSP, наверное где-то рядом был только YCM.

Может ошибочно подтекст прочитал, но ощущение такое, что они - всё. Да они и сейчас вроде ничего. Наличие LSP не отменяет их, с сервером все равно должен кто-то общаться. Тот же YCM сейчас общается с сервером через LSP (видимо просто надежней, ибо стабильнее шланговского libclang апи). Да и альтернативы какие? Какой-нибудь CoC на жаваскрипте? Уж лучше YCM с нативом, да он и поудобнее.

Они ещё долго будут ничего, просто это примерно как десктопы 90ых и современные. Болезни именно архитектурные, это прототипы которые подтолкнули и позволили сделать следующую генерацию решений. Т.е. заслуженные такие пионеры, но уже в предпенсионном состоянии.

Для vim и lsp есть тот-же vim-lsp на чистом viml там автор твои вот эти взгляды и разделяет, типа CoC фу, нахрен лишнее тащить.

Чтобы ты понимал разницу - YCM и rtags реализуют свой доморощенный протокол, заточенный только под c-family, плохо документированный и местами плохо спроектированный(например супер завязанный на транспорт протокол rtags). LSP же это как-раз протокол, который постарался эти(и другие) опыты в себя вобрать, притом с учётом множества языков. Т.е. YCM это сразу всё и плагин к виму(а после и к емаксу) и «языковой сервер» и протокол. А LSP позволяет все эти компоненты менять. Например для плюсов минимум 2 живых реализации есть ccls и clangd, было больше но не все потянули прогресс протокола в момент когда там активная разработка шла. Типа разделяй и властвуй.

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

Сначала был YCM в виде vim биндинги для libclang(ещё были vim-clang и куча клонов попроще). Потом - появился rtags и это было «вау», т.к. в vim не надо было тащить какой-то зависимости от libclang(но формат протокола это lisp и заточено всё конечно под emacs), клиент работал уже в терминах языка а не API libclang. Затем YCM переобулись и сделали протокол на json-rpc и тоже clang-related код пропал из плагина для vim. Спустя какое-то время появился VSCode как первая реализация LSP, и через какое-то время случилась публикация протокола и началась активная работа над его развитием. В наши дни протокол более менее стабилизировался и идут тёрки за пару спорных расширений типа semantic higlight и т.п.

Ну так рассуждаешь, буд-то LSP решает все проблемы, на другой стороне у нас все равно остается жирный клиент, который работать будет медленней, чем напрямую линкуясь с libclang, но да - взамен универсальность и разные серверы.

vim-lsp на чистом viml

Вот это и проблема, это ведь все тормозное, сам автор пишет

Performance

Certain bottlenecks in Vim script have been implemented in lua. If you would like to take advantage of these performance gains use vim compiled with lua or neovim v0.4.0+

А YCM bottlenecks написал на Ц/Ц++. И ничего YCM не мешает начать работать с разными серверами питоновскими или иными, там тот же LSP с внешним миром. Т.е. ничем оно не отличается по большому счету (кроме языка). И я почти уверен, что если полезть потыкать это vim-lsp, то не будет какой-нибудь signature help (я много всего пробовал, запомнил бы что-то годное).

В наши дни протокол более менее стабилизировался и идут тёрки за пару спорных расширений типа semantic higlight

Слишком тормозит такая подсветка.

Видимо у нас какие-то разные

Да, я пользовался более древней «оригинальной» версией и она умела в:

ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q ...

В новой версии сломали или что?

Я подозреваю, что самодельный парсер будет работать намного быстрее и потреблять меньше памяти.

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

Анализ наследования в задачи дерева не входит.

Для автокомплита - входит, без него не будет родительских членов / методов.

Для vim

При всем уважении я не советую вим для крупных проектов. Поверьте, я причисляю себя к элите С++ программистов и знаю о чем говорю …

Владимир

Я с опциями не пытался. Тогда хз, может и умеет что-то, но сомневаюсь, что много.

Ещё вопрос

Как сгенерить compile_json database для загруженного чьего-то проекта? compile_flags.txt не вариант. У меня нет всех необходимых зависимостей (и я не хочу их ставить), проект на Cmake. Передо мной сейчас исходники clang на ЦПП, надо его поковырять, там куча подпроектов, нужны корректные пути для всяких -I…, конфигурирование с CMAKE_EXPORT_COMPILE_COMMANDS заканчивается ошибками (нет зависимостей). Как проигнорить все ошибки find_package() и подобные?

Прочти уже, наконец, документацию.

Я с опциями не пытался.

Я так и понял, что ты у мамы не читатель.

Я их не сегодня пробовал, много времени прошло, может и опции какие передавал - не помню. Пришел лишь к мнению - для ЦПП это не годится. Вот скажи какие опции правильные надо передать, я проиндексирую шланг и скажу что получилось.

Ох уж эти знатоки боттлнеков и тормознутости. Есть такая фишка как RDMA например. О-да, оно конечно медленнее оперативки, но твой десктоп (если ты захочешь в эту глупую затею вбухать пару лишних лямчиков) разницы не заметит скорее всего, а web-сервер точно не заметит, хотя память будет работать от 100 до 1000 раз медленнее. На задачах заточенных под человечий глаз уж и подавно не увидеть разницы между lua и крестами.

Слишком тормозит такая подсветка.

Про тормоза подсветки в vim это явно отдельная тема, tl;dr её таки пофиксали но не всё ещё на неё переехало. Про тормоза semantic higlight, да и вообще любые другие тормоза, говорить что-то без замеров это ну такое себе комильфо. Что именно тормозит? Где узкое место? В передаче данных по петле? А может таки в рендеринге? А почему rdp на пинге 5 не тормозит, а на петле тормозит какая то жалкая отрисовка цветов для текстовы токенов в пределах видимого пространства отрисовки?

А можно раскрыть почему? И чем например лучше пользоваться?

Geany. Медленно открывает файлы.

На Gtk3 что ли собрал?

Вот скажи какие опции правильные надо передать,

Ты специально меня траллишь запросами на ссылки на сообщения в этом же треде? Или ты просто вырос на твиттере и тиктоке?

Тут есть встречный вопрос - а как ты собираешься различать код под разные платформы при навигации, если твой тул не знает под какую платформу оно «загружено»?

Ну и тот же ycm/rtags тоже полагается на compilation database шланга, да там просто есть какой-то дефолт, но с тем же шлангом ты на нём далеко не уедешь.

Ctags тут компромиссное решение, но навигация будет «на глазок», зато компилять не надо. Подходит в общем и целом видимо для каких-то непонятных теоретиков, или тех нехороших людей которые отлаживают проекты на CI со временами билда по несколько часов, прожигая впустую и своё и машинное время.

Ох уж эти знатоки боттлнеков и тормознутости.

Ну а в итоге - архитектурно vim-lsp и YCM идентичны примерно, lsp протокол для внешного мира и набор vimscript интерфейса внутрь. А что они там со своими боттлнеками делают - это уж их ливер.

Про тормоза semantic higlight, да и вообще любые другие тормоза, говорить что-то без замеров это ну такое себе комильфо.

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

В общем инфа твоя - брехня. Ничерта ctags не справляется ни с перегрузкой, ни с разными пространствами

struct S {
	void f(int i);
	void d(double d);
};
struct Q {
	void f(int i);
	void d(double d);
};

int main() {
	S s;
	Q q;
	int i;
	double d;
	s.f(i);
	q.f(i);
	s.f(d);
	q.f(d);
}

что было очевидно т.к. ctags не занимается синтаксическим анализом. А шаблоны я даже пробовать не стал, если на такой элементарщине уже фейл. А опции твои брал.

Ну а в итоге - архитектурно vim-lsp и YCM идентичны примерно

Примерно - да, вопрос в степени примерности :) Иксы и вэйланд тоже примерно архитектурно идентичны. Есть небольшая разница в детальках и разница в десяток другой лет в начале их эволюционного пути, а так-то примерно, да.

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

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

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

Можно пример кода? Пока я вижу, что для генерации дерева объявления исключительно для навигации по коду (не автодополнение, cross-ref и т.п.) шаблонные объявления можно просто пропускать.

Для автокомплита - входит, без него не будет родительских членов / методов.

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

Ничерта ctags не справляется ни с перегрузкой, ни с разными пространствами

И где я тебе это обещал?

для одного файла

А при чём тут си (++) ?

А при чём тут си (++) ?

При том что C/C++ записывается в текстовых файлах.

ничего легковеснее Geany нету. по крайней мере я не находил. все либо глючное либо не функциональное.

Ещё бы оно научилось запоминать настройку не сортировать символы по имени. Может быть я не нашёл где оно меняется.

opensource же!

для одного файла

в текстовых файлах

Именно. С одним файлом максимум фибоначчи можно записать.

Именно. С одним файлом максимум фибоначчи можно записать.

Исходники на C++ можно без проблем редактировать по одному безо всяких проектов. Если с этим какие-то проблемы, то архитектура и стиль кодирования плохие.

Исходники на C++ можно без проблем редактировать по одному

Ты определись - тебе «исходники редактировать в одном файле» или корректную навигацию по именам символов?

Требует аккаунт для установки.

Нет. Бери не с сайта.

Ты определись - тебе «исходники редактировать в одном файле» или корректную навигацию по именам символов?

Одно другому не мешает и много где приемлемо работает.

Навигация по коду – это большие требования? Это умеет примитивный редактор Pe для BeOS/Haiku из 90-х годов с размером 1.25 МБ.

Так может быть тогда, Linux и Windows дерьмовые системы, и пора переходить на Хайку?

Для винды правда :( Но там бесплатно.

Навигация вне проекта без настроек инклудов? И как это должно работать?

Навигация вне проекта без настроек инклудов? И как это должно работать?

Легко: написано SomeClass::SomeMethod() и оно добавляется в дерево. Тоже и для содержимого class/struct{...};. Содержимое инклудов добавлять не надо.

Здравствуй X512 мороз,
Борода из ваты,
Ты подарки нам принёс,
А, горбатый?