Re: unbuffered remote process I/O

[Felipe Lema]

Hey, Michael

I just wanted to let you know that I've received your request of
providing a self-contained example, but it's taking me longer than I
expected.

TBH, this might take a couple of weeks because of contingency and my
own lack of knowledge of the json-rpc.el package.

Felipe

On Fri, 2020-05-15 at 18:38 +0200, Michael Albinus wrote:
> 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.