LSP_Python_in_Vim8x

yegappan/lsp

Вот это. Обнови vim просто. У них есть официальный AppImage.

А тут гляжу LSP для Go на go, LSP для rust на rust. Все как то странно.

А на чём они, по-твоему, должны быть написаны?

Да я вас понимаю, и про скорость vimscript9 и т.д., но все таки хотелось бы под vim8, так как в el9.6 все еще 8х по умолчанию.

Так vim компилируется без особых проблем…

yegappan добавил в vim кучу необходимого для работы lsp и у него пожалуй лучший для него клиент сейчас.

в el9.6 все еще 8х по умолчанию

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

Ну может я просто не совсем понимаю принцип работы, я думал что это должен быть какой то отдельный сервис на си, go, rust где есть директория language и туда грузяться плагины для разных языков.

LSP это протокол. Для каждого языка есть независимые, вообще отдельные реализации серверов, работающие по этому стандартному протоколу.

Да я все понимаю, этот вариант понял.

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

Вон статья про VIM IDE там автор не использует это.

Странно как то, вон из статьи про VIM IDE там используется LSP сервер на node.js т.е. в принципе можно сделать один сервер для всех.

Извините но можно вернуться к обсуждению вариантов? Пока предлагают только 1 вариант - поднять vim до 9 и заюзать : yegappan/lsp.

Странно как то, вон из статьи про VIM IDE там используется LSP сервер на node.js

coc.vim? Это LSP-клиент, серверы используются обычные.

Хм. Для LSP клиента, для python юзать клиент на на nodejs ? Хм однако…

P.S. Начал читать про vim9 в el9, напоролся на https://stackoverflow.com/questions/77973076/vim-fails-to-compile-on-rhel-9-with-clang-file-format-not-recognized

вот этот: https://github.com/vim/vim-appimage/releases/tag/v9.1.1473 ?

Народ советуют поставить vim из snap или flat :( Мда уж:(

Попробовал это appimage

./Vim-v9.1.1473.glibc2.34-x86_64.AppImage 
/tmp/.mount_Vim-v9fFcGON/usr/bin/vim: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by /tmp/.mount_Vim-v9fFcGON/usr/bin/../lib/libtcl8.6.so)
/tmp/.mount_Vim-v9fFcGON/usr/bin/vim: /lib64/libm.so.6: version `GLIBC_2.35' not found (required by /tmp/.mount_Vim-v9fFcGON/usr/bin/../lib/libruby-3.0.so.3.0)

rpm -q glibc
glibc-2.34-168.el9_6.19.x86_64

Они там что? Совсем уже не понимают что пишут?

у меня есть репа с конфигом для vim. там lsp. а кроме ноды вариантов нет, если тебе нужно автоматом все настраивать, усианавливать

поставь из snap. appimage - мусор. хотя что мешает из исходников собрать, snap-версия не пригодна для использования lsp… да. appimage или исходники - разницы нет

Совсем уже не понимают что пишут?

Кто? У тебя libc слишком старая. Собери руками, это не сложно. Разве что огромное количество флагов, которые придётся указать явно, чтобы точно были нужные фичи.

Зачем у них в имени файла: glibc2.34 ?

Они там ее собирают на Ubuntu 22.04 LTS а там glibc 2.35 и зачем они пишут что 2.34 я не совсем понял.

Взял собраной на Ubuntu 20.04 Vim-v9.1.1301.glibc2.29-x86_64.AppImage - это пашет.

Не пойму зачем народ обманывать :(

Вероятно, просто перепутали :)

Мда уж:(

Кстати вот кому интересно: https://langserver.org/

Там у вас в статье:

Альтернативой coc является vim-lsp. Он так же как и первый работает через языковой протокол LSP. Его настройка несколько сложнее: coc ставит расширения автоматически с языковыми серверами, которые у них указаны в зависимостях.

С использованием vim-lsp языковые сервера нужно ставить самостоятельно:

насколько я понял, если поставить : Plug ‘mattn/vim-lsp-settings’

То все автоматом прокатывает.

Истинно говорю вам, пройдет еще полгода и те кто спрашивали как вкорячить протокол LSP начнут спрашивать как вкорячить протокол MCP…

Покайтесь, ибо грядет.

если нужен полноценный Python LSP то единственный вариант это бинарная сборка VSCode от MS с их проприетарным Python extension

Да уже каемся, пепел заказали, едет из Индонезии.

Почитал статью: Делаем из Vim IDE, там coc.vim, да ну нафиг всякие node.js :(

coc

Ну а чё ты хотел.

Насколько я понял для питона в vim9 вообще ни какой LSP не нужен.

На лишпе

А что тебе нужно-то? Без LSP только совсем базовые вещи вроде подсветки синтаксиса и выравнивания. Как вариант, есть плагин для интеграции с Jedi, без LSP. Если нужен только Python, то сойдёт.

Без LSP там дополнение и хелп по документации, точно также как и с LSP. Без всяких Jedi и т.д.

Единственно что нет проверки синтаксиса и дебаггера, но вон у автора статьи это ALE и vimspector.

Не, ну как, встроенные решения и плагины-то есть. Но с lsp веселее.

эти авторы vim appimage не совсем понятные, там glibc жестко прибита 2.35 и собран он с python 3.8, в el9 установлен 3.9 и их vim родного питона не видит :(

Короче остановился я на плагине: vim-lsp.

И по логике всякие ALE и т.д. теперь нафиг не нужны. Только что то у меня не получается vim8x настроить на дополнение по TAB.

в vim9 пашет а тут нет :(

Есть кто юзает vim-lsp?

Ещё natebosch/vim-lsc есть, кстати. Лёгкий, настраивается гораздо проще, чем vim-lsp. Rename, Hover и прочее - все работает как полагается (если LSP сервер умеет). Куча кейбиндингов по умолчанию.

Вот только не помню, с каким из двух были глюки, связанные с вываливанием ошибочных сообщений от LSP. По-моему всё-таки vim-lsp.

А, и применительно к питону:

Plug 'natebosch/vim-lsc'
let g:lsc_auto_map = v:true
let g:lsc_server_commands = {
    \ 'python': {
        \ 'command': 'pylsp'
    \},
\}

И всё, собственно.

Да я видел его, меня остановил то что последний коммит там был 2 года назад …

В vim8 последний коммит был, наверное, ещё раньше. На условном neovim 0.8 сейчас, вероятно, не заработает 90% плагинов.

Тут еще какая странность, почему то поддержка одного плагина lsp не обеспечивает то что заявлено в нем. Хотя по идее все должно работать.

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

Ты сначала поработай с этими lsp плагинами, а вдруг они кривые и тормозные. Все макаки сбежали на неовим неспроста. ALE простой и надежный как топор. Можно с lsp сервером не сношаться, но получишь интеграцию с линтерами. Часто большего и не требуется.

если просто чекер то того же: vim-syntastic/syntastic за глаза.

(сейчас про тормознутость сложно писать когда куча ядер и рам от 32)

Проверил я lsc на vim8, поскольку там по умолчанию включено авто дополнение и ненужно жать tab, то подсказка сразу всплывает. Так что по сути работает лучше чем vim-lsp.

Для питона лучше всего LSP + pyright-langserver

Насколько я понял он node.js притащит :(

Да я вас понимаю

Да ничё ты не понимаешь! Бери Coc, если работать.

А тут гляжу LSP для Go на go, LSP для rust на rust. Все как то странно.

чтобы ты понимал, Treesitter на Rust.

Вообще я пришел к выводу что LSP должен входить в базовый состав языка того что ты используешь для написание проги.

К примеру ставит python13 и у него должен быть рядом пакет python13-lsp.

Потом чел просто берет любой IDE ставит туда плагин IDE-LSP и все сразу готово.

Бери Coc, если работать.

Раз вы уже заговорили про coc, объясните мне зачем автор статьи vim-IDE ставит к coc еще и ALE?

чтобы ты понимал, Treesitter на Rust.

Предлагаю не говорить, на чём написаны грамматики к нему.

Вообще я пришел к выводу что LSP должен входить в базовый состав языка того что ты используешь для написание проги.

Хорошо бы, но это так обычно для относительно новых языков. У Python нет официального LSP-сервера, а самый популярный — с закрытым кодом, если не открыли ещё.

Хорошо бы, но это так обычно для относительно новых языков. У Python нет официального LSP-сервера, а самый популярный — с закрытым кодом, если не открыли ещё.

Не совсем так. pyright - открытый код, на котором базируется закрытый pylance. У pylance больше возможностей, но мне вполне хватает возможностей pyright, а то, что меня не устраивает в pyright, не исправлено и в pylance.

ALE специализируется на линтинге, так что нормальная идея. Более того, в ALE есть LSP-клиент 🤯

Спасибо, полезное уточнение. Я не очень по Python, так что толком не разобрался, насколько полезен pyright без проприетарного кода Microsoft.