[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New jrpc.el JSONRPC library

From: Josh Elsasser
Subject: Re: New jrpc.el JSONRPC library
Date: Sun, 20 May 2018 20:32:38 -0700

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 
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 
support in the next couple days. I’ll need to add an extra per-proc variable to 
a required initialzationOptions param (persistent cache directory), but that 
prove too difficult.

-- Josh

reply via email to

[Prev in Thread] Current Thread [Next in Thread]