Re: unbuffered remote process I/O

[Michael Albinus]

Felipe Lema <address@hidden> writes:

> Hey, Michael

Hi Felipe,

> The purpose of LSP is to unify and centralize the events of editing a
> certain project (say, editing the linux kernel code). IDEs are commonly
> built-up from scratch (syntax highlighting, building binaries, linting,
> nvim emulation) in a specific platform (Netbeans-Java, Emacs-elisp,
> CLion-Java, Eric-Python). LSP decouples the language-specific and
> platform-specific features from the IDE into a server.
>
> In this scenario, syntax checking and linting happen in the server. The
> IDE translates events from and to the server ("a source file changed",
> "a line throws a compile error"), presents events to the user ("this
> line is throwing error, this is the suggested fix"). See [1] & [2] for
> further info.
>
> In my case, eglot is a package that translates Emacs events to the
> server (after-save-file-hook -> "file was changed") and events from the
> server to the user interface ("compile error at x,y" -> show as
> flycheck error).
>
> LSP servers work on machine-local files (not bytes from a buffer, since
> they are aware of other files in the project), so if I'm editing a
> remote file with Tramp, I need to load the server on the remote
> machine.
>
> The communication is asynchronous, sending json objects back and forth
> as. The communication does not include new-line (it can, but it's
> uncommon) and the size of the objects is arbitrary (a size-in-n-bytes
> is sent before each object). Because of this particular I/O, I need to
> have unbuffered communication between Emacs and the remote server.
>
> By the way, it uses JSON-RPC for communication, not msgpack-rpc. That
> was my mistake.

Do you have a simple step-by-step recipe for playing with this, starting
with "emacs -Q"?

> Thanks for the help.

Best regards, Michael.