emacs-devel
[Top][All Lists]
Advanced

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

Re: [ELPA] New package: dape


From: Daniel Pettersson
Subject: Re: [ELPA] New package: dape
Date: Sat, 4 Nov 2023 10:51:04 +0100

On Wed, Nov 1, 2023 at 7:35 PM Philip Kaludercic <philipk@posteo.net> wrote:
> Did we ever come to a conclusion on this point?

Sorry I have been putting the naming thing off as this thread sparked
a bit of interest in the package which lead to a lot of great input and
bugfixing. There have been a lot of good suggestions and no consensus
which has made the even task harder.

On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:
> Just found out about this initiative, great stuff.

Thanks for the encouragement.

> I especially like the fact that like Eglot, it seems to be completely
> language agnostic and doesn't require little dape-<language>.el
> add-ons.
>
> But shouldn't it be using jsonrpc.el?  It seems to implement
> that base protocol all over again, much like eglot.el did
> in its early days. Was this intentional, is there a limitation
> in jsonrpc.el that should be addressed?

Would be great to reuse jsonrpc but for some extremely strange reason
DAP is not an JSONRPC 2.0 protocol.

https://microsoft.github.io/debug-adapter-protocol/specification#Base_Protocol_ProtocolMessage

It's close but not close enough, it's able to reuse jsonrpc process
filter but it falls to pieces in `jsonrpc-connection-receive', due to
slight differences in the protocol. The protocol request/response id is
replaced by seq or request_seq and method is command in DAP to name a
few differences.

If jsonrpc is generalized of any jsonrpc like protocol DAP could make
use of it, but I don't know if that would be a good idea.

> As to the name, I think "dape" is fine.

You would be the first one :) or maybe the second one as someone in
the reddit thread said "dape is dope".



reply via email to

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