А в чём сложность подключать разные LSP-серверы к VIM?

А в чём сложность подключать разные LSP-серверы к VIM?

Вим не поддерживает ЛСП. Неовим поддерживает.

Звучит кстати ущербно(хотя это не так), но правда. Инверсия зависимостей наше всё, иначе получаются монолитные монстры. Тот же линупс кернел вполне себе пример. Тут бы Линусу у Брэма поучиться.

LSP появился 2016, а VIM прошлом веке. Кто о ком должен знать?

Плюс разные серверы не поддерживают те или иные фичи языка. Плюс, раз выделили парсинг в микросервис, то хорошо бы выделить и сборку с отладкой (BSP). Плюс само автодополнение в vim и до LSP требовало плагинов для хорошего look&feel. В IDE с поддержкой LSP все эти пляски автоматизируют языковые плагины, а в vim принято настраивать под себя.

почему не существует тупого списка LSP-серверов в виде гитхаб-проектов, которые можно собрать и виму прописать в однообразный конфиг

Это сделать можно. Другое дело, что «собрать LSP-сервер» — это значит «поставить типовые гигабайты инфраструктуры языка». И все равно получится плохо, потому что «помощь при редактировании сорцов» ≠ «распарсить вылизанные сорцы из прода» — и ничего ты с этим не сделаешь, нужно идти на разного рода уступки, чтобы было удобнее редактировать недописанные сорцы.

Ну и да, Vim в голом виде в LSP не умеет, потому что Vim давно устарел. Зато он имеет кучу бесполезных высокоуровневых фич из коробки.

А чтобы по javascript-файлам ходить, они уже не могут просто прописать какой-то LSP-сервер для JS, а там какая-то своя грёбля.

Могут, тема гребли не раскрыта.

Но да, надо с coc слезть в сторону нативного LSP neovim, раз завезли.

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

Как это не существует?

https://microsoft.github.io/language-server-protocol/implementors/servers/

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

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

Во-вторых LSP-протокол поддерживает только самые популярные фичи, общие для всех мейнстримных языков. Многих языко-специфичных фич там тупо нет. Например протокол не поддерживает переключение между .cpp и .h файлами, ибо это нужно только в C/C++. В итоге поддержку всех нестандарных фич нужно дописывать на стороне клиента для каждого редактора по отдельности.

Вот и получается, что голых LSP-серверов недостаточно, все равно во многих случаях надо городить LSP-клиенты. Любо-дорого посмотреть, сколько всякой писанины нужно на стороне клиента для питона например. А потом плагинописатели благополучно передирают все эти клиентские расширения и портируют их к себе на вим (coc-python, coc-pyright и т.д.)

Может тогда еще уникод виму научим? Было бы неплохо набирать прям в нормал моде.