emacs-devel
[Top][All Lists]
Advanced

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

Re: [ELPA] New package: dape


From: João Távora
Subject: Re: [ELPA] New package: dape
Date: Sat, 4 Nov 2023 23:21:35 +0000

On Sat, Nov 4, 2023 at 9:51 AM Daniel Pettersson <daniel@dpettersson.net> wrote:
>
> 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.

I, like others, am of the opinion that you should spend little to no
time in this naming bikeshedding discussion.  Reserve that energy
for things that actually matter.  Dape or Daisy or Alberto are fine
names for this package.

> On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:

> 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.

Ah, I see.  Indeed it's very strange that it's not JSONRPC.

So I see the main difference, and it's the one you mention.  It seems
that if I were to change jsonrpc.el sufficiently to accomodate that particular
difference, then it _could_ be used.

Do you know of any other significant/fundamental differences (say, such as a
message type which is neither a request, nor a response, nor a notification)?

If I were to try to do these jsonrpc.el changes to accomodate DAP protocols,
would you accept a PR to dape.el adding jsonrpc.el as a dependency to
dape.el?

João



reply via email to

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