Re: New jrpc.el JSONRPC library

[Josh Elsasser]

Clément Pit-Claudel <address@hidden> wrote:

> Thanks for the positive feedback, and indeed creating a clean API was a
> design goal, but notice that:
> 
>  (cl-defun eglot--server-myLangServer/customMethodName
>     (proc &key param1 param2)
>     ...) 
> 
> has two dashes in it. It isn't (yet) a part of the official eglot.el LSP
> API, and your particular example might very well become something like:

Ah, fair. I was mostly thinking aloud about extending the current GitHub master
with cquery support, which'd mean hideifdef support (if I was going to use it
at my day job, at least). May’ve been getting a little ahead of myself :)

> 
>  (cl-defmethod eglot-handle-notification
>     (proc (method (eql :myLangServer/customMethodName)) &key param1 param2)
>     ...)
> 
> or, for requests
> 
>  (cl-defmethod eglot-handle-request
>     (proc id (method (eql :myLangServer/customMethodName)) &key param1 param2)
>     ...)
> 
> This seems cleaner than the "automagical" function names, although it
> has two minor drawbacks:

IMHO the cl-defmethod approach looks a lot nicer for someone hoping to build off
eglot. Took a bit of headscratching to make the connection between the intern +
fboundp and having the various handler functions, and I could see it being a 
pain
to manage scores of magic functions scattered throughout files.

Can’t wait to give eglot a spin, though! I’ll try and implement / test basic 
cquery
support in the next couple days. I’ll need to add an extra per-proc variable to 
pass
a required initialzationOptions param (persistent cache directory), but that 
shouldn’t
prove too difficult.

-- Josh