Re: The client/server protocol?

[HiPhish]

Thank you for the answer. That sounds pretty simple, I'll give the Guile 
server a try and see if I can interact with it directly. Can you please point 
me to where Emacs starts the Guile process?

As for the different implementations, I am aware of the issue. My idea was to 
get things to work with Guile first, and then write implementation-specific 
adapters. That way I can write the editor client once, reuse the existing 
server implementations and only write the adapter layers. That's less work 
than creating an entire editor plugin for every individual implementation.

On Sunday, 11 April 2021 23:56:17 CEST Jose A. Ortega Ruiz wrote:
> Hello,
> 
> On Sat, Apr 10 2021, HiPhish wrote:
> > Hello,
> > 
> > I'm a Neovim user and I would like to try porting Geiser to Neovim. From
> > what I understand Geiser consists of two parts: the client (Emacs part)
> > and the servers (the Scheme part, a separate server for each
> > implementation), similar to how Slime works. Obviously the client will
> > have to be rewritten, but I would like to reuse the servers.
> > 
> > My question is, how do the client and server communicate? How does the
> > client start the server? Which messages do they exchange? I know how to
> > read Scheme and Common Lisp, but I don't know Emacs Lisp. The
> > implementations I am most familiar with are Guile and Racket.
> > 
> > I want to be able to perform at least a simple handshake for starters,
> > that
> > should be enough to nudge me in the right direction. Just running the
> > server from the command line and exchanging messages over stdio per hand
> > would be all I need, I can figure out the Neovim side of things myself.
> 
> The protocol between Emacs and the scheme process is very simple-minded.
> By default, Emacs is just running a repl and sending sexps to its
> standard input, capturing the result from the process standard output
> and expecting it to be a scheme a list with possible (symbol) keys:
> 
>       result - if the evaluation is sucessful, its results; the value is
>       a list of scheme expressions, the returned values
>       output - if the evaluation produced any output as a side-effect,
>       it comes as a string under this key
>       error - if an error occurred, this key will be present, its value
>       being an alist with (optional keys) 'key and 'msg, identifying the
> 
> That's all there is to the protocol: the unification among all the
> scheme implementations happens on the emacs side, where we define a
> uniform interface to perform the different operations that results in
> calling scheme-side functions.  So to test how this works with, say,
> Guile (the best supported implementation), you can simply start a repl,
> enter or use the (geiser) module and call the functions it exports with
> the prefix ge:  (ge:eval, etc.).
> 
> A problem you'll find with that is that the scheme side is not standard
> at all among implementations.  Each scheme is free to implement de
> emacs-lisp generic protocol as it's more convenient to the
> implementation.  For instance, guile and racket use ,-commands (each
> defined with in their own way), while others like chicken expose
> directly a private scheme API, and their elisp side is responsible to
> map that API to the Geiser standard emacs API.
> 
> The obvious problem with that is that, to use all this on neovim, one
> has to learn each separate scheme implementation API.  I know this must
> sound like a really poor design, but the problem here was that each
> implementation basically defines a different language, specially when it
> comes to modules and introspection primitives, which are they precisely
> the most important ones for Geiser, so it would had been really hard
> defining a common API on the scheme side.  Maybe if this SRFI idea
> https://gitlab.com/emacs-geiser/geiser/-/issues/7 we will have a better
> scenario, but that's probably years away in the best case. You'll see in
> the brief discussion
> https://srfi-email.schemers.org/srfi-discuss/msg/14669041/ that
> everybody likes the idea, but it's a giant job.
> 
> Probably the best (or more feasible) action would be to choose a scheme
> and reuse it to provide a Neovim interface for that scheme.  In my
> experience, it's what users want.  For instance, despite being as
> complete as Guile's, Racket's geiser implementation was essentially
> ignored, to the point of remimplementing many bits of it in racket-mode,
> a specific emacs integration for Racket.  Given that they're essentially
> different languages, i guess it makes sense... but then the same
> applies, i'm afraid, to many other schemes.
> 
> Cheers,
> jao