чтение из именованного канала UNIX (fifo) в буфер [neo] vim - PullRequest
Новая
       37

чтение из именованного канала UNIX (fifo) в буфер [neo] vim

0 голосов
/ 28 февраля 2020

В настоящее время я пытаюсь создать серверную клиентскую архитектуру для любой программы, использующей каналы в качестве своих stdin и stdout.

У меня работает весь сервер, и он взаимодействует через именованные каналы (fifo). Я пытаюсь постоянно (асинхронно) читать содержимое канала stdout в буфер vim, и я ищу наиболее элегантное решение этой проблемы.

Скажем, у меня есть программа, python, связь через 2 (3, если вы используете аккаунт stderr, но это не имеет отношения к поиску решения), а именно PIPE_IN в качестве его стандартного ввода и PIPE_OUT в качестве его стандартного вывода.

Я могу написать в канал легко из vim (с :w), как бы я прочитал из PIPE_OUT в буфер vim или neovim?

Однако он не должен переноситься на системы, отличные от UNIX Я хотел бы сохранить совместимость как с vim, так и с neovim, насколько это возможно. Что бы вы посоветовали для этого? Должен ли я использовать язык Vimscript для этого? В этом случае лучше использовать режим командной строки vim? Какие другие, возможно, более элегантные решения, я пропускаю?

Заранее спасибо!

Примечание: код проекта сервера можно найти по адресу Soulthym / pyper на GitHub для цели тестирования.

1 Ответ

1 голос
/ 29 февраля 2020

NeoVim и современные Vim поддерживают каналы , которые можно использовать для асинхронной связи с внешними компонентами.

В частности, NeoVim поддерживает sockconnect(), который поддерживает именованные трубы:

Подключите розетку к адресу. Если {mode} равно "pipe", тогда {address} должен быть путем к именованному каналу. [...] Возвращает идентификатор канала.

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

(Если оставить в стороне, но рассмотрите возможность использования Unix доменных сокетов, а не каналов, они намного более функциональны. Они двунаправлены, поэтому вам не нужно их несколько пар. Также вы можете использовать их для реализации серверов, которые могут прослушивать и принимать несколько соединений по одному адресу.)

...