[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unbuffered remote process I/O
From: |
Felipe Lema |
Subject: |
Re: unbuffered remote process I/O |
Date: |
Fri, 15 May 2020 11:35:47 -0400 |
Hey, Michael
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.
Thanks for the help.
[1] = https://microsoft.github.io/language-server-protocol/overviews/ls
p/overview/
[2] = https://en.wikipedia.org/wiki/Language_Server_Protocol
On Fri, 2020-05-15 at 10:52 +0200, Michael Albinus wrote:
> Felipe Lema <address@hidden> writes:
>
> > Sup, yo
>
> Hi Felipe,
>
> > I'm having some trouble with a Tramp-remote process created using
> > `make-process` and it's 27's :file-handler parameter. It seems that
> > the
> > Emacs process is not receiving input bytes or not receiving output
> > bytes because of buffering.
> >
> > Context
> > -------
> >
> > I'm working on tramp support for the eglot package[1]. eglot is a
> > bridge between a LSP server and Emacs, translating events from
> > either
> > side to the other using msgpack-rpc through stdin and stdout.
> >
> > After starting the process, eglot rpc-calls for an initialization
> > methods (ie: sends bytes) and expects a result (ie: reads bytes)
> > within, let's say, 30s.
>
> I'm trying to understand your architecture, and how Tramp relates to
> this. Which process do you start remotely? Is it an LSP server? I
> suppose that eglot itself (as LSP client) runs locally, right?
>
> Please take into account that I'm a n00b wrt LSP and eglot.el.
>
> > Thanks
> > Felipe
>
> Best regards, Michael.
- unbuffered remote process I/O, Felipe Lema, 2020/05/13
- Re: unbuffered remote process I/O, Michael Albinus, 2020/05/15
- Re: unbuffered remote process I/O,
Felipe Lema <=
- Re: unbuffered remote process I/O, Michael Albinus, 2020/05/15
- Re: unbuffered remote process I/O, Felipe Lema, 2020/05/19
- Re: unbuffered remote process I/O, Michael Albinus, 2020/05/20
- Re: unbuffered remote process I/O, Felipe Lema, 2020/05/21
- Re: unbuffered remote process I/O, Michael Albinus, 2020/05/31