LINUX.ORG.RU

http server в vim

 , ,


0

3

Если бы я вдруг захотел http сервер в vim(8.x) и nvim, который который при обработке запросов вызывал произвольные команды vim, то на какое api мне бы стоило бы посмотреть?

Сам сервер я бы предпочел написать на python.

Резюме: подружить event loop vim'a с многопоточным скриптом реализующим web сервер на данный момент прямого и простого способа нет.

Возможные варианты:

  • использовать вариант +server, при обработке запроса в коде web сервера запускать новый процесс vim, и выполнять на сервере код с помощью --remote-expr
  • Использовать функционал +job/+channel

Я предпочту вариант +job/+channel, т.к. там поддерживается автоматическая обработка выполнения различных комманд и выражений vim в json ответе от job'a, см. раздел справки channel-commands. Соответственно, viml часть можно свести к запуску job'a, всё остальное можно сделать из кода сервера. Хотя, можно и видимо лучше таки определить клиентские функции инициирующие дальнейшую работу в viml части.

★★★★★

Последнее исправление: pon4ik (всего исправлений: 1)

Ответ на: комментарий от andreyu

А это poc к ней.

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

Есть конечно +remote, но пока что, выглядит это не очень. Есть ещё вариант с поллингом на таймере конечно, но тоже мне не очень нравится.

pon4ik ★★★★★
() автор топика

channel.txt:

let channel = ch_open('localhost:8765')
И там JSON есть для (де)сериализации данных. Но не знаю, насколько оно в python-интерфейс выставлено.

xaizek ★★★★★
()
Ответ на: комментарий от pon4ik

Есть конечно +remote, но пока что, выглядит это не очень.

А чем плох?

Есть ещё вариант с поллингом на таймере конечно, но тоже мне не очень нравится.

Не, полниг по таймеру не фонтан.

andreyu ★★★★★
()
Ответ на: комментарий от xaizek

Смотрю как раз на него сейчас. Только вот он для случая когда vim есть клиент насколько я пока что разумею.

А мне нужно, сделать так что бы vim был сервером. Хотя видимо тут уже можно что-то придумывать. Если уже всё придумал, вдруг, расскажи, дабы ускорить процесс.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от andreyu

А чем плох?

Как минимум тем, что лишний протокол добавляется.

Ещё сервер должен быть проименован, придётся придумывать механизм именования.

Ещё, в текущей задумке лишний компонент выходит, а их там и так 3 (мастер сервер, сервер gdb и сервер vim).

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Чё-то я думал, что оно может и сервером быть, но не видно этого. Я бы тогда попробовал из питона это делать его средствами.

xaizek ★★★★★
()
Ответ на: комментарий от xaizek

Ну поднять то сервер из питона ноу проблем, а вот как коммуницировать с event loop vim'a непонятно.

Вот в gdb для этого есть специальная дырка в api - post_event.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Не уверен, что код на питоне выполняется вне event loop'а в Vim'е. В крайнем случае эквивалент post_event можно соорудить сделав канал между питоном и viml. Я бы, наверное, спросил в рассылке Vim'а, чтобы наверняка.

xaizek ★★★★★
()
Ответ на: комментарий от xaizek

Код на питоне выполняется ессно в пределах цикла обработки событий, однако, есть multi(thread|process)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от urquan

Что угодно может быть сервером с помощью socat и такой то матери :)

pon4ik ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.