Re: The client/server protocol?

[Jose A. Ortega Ruiz]

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
-- 
Be humble, for you are made of earth.
Be noble, for you are made of stars.
  -Serbian proverb