Re: [ELPA] New package: dape

["João Távora" <joaotavora@gmail.com>]

On Tue, Nov 7, 2023 at 10:19 AM Daniel Pettersson
<daniel@dpettersson.net> wrote:
>
> > > On Thu, Nov 2, 2023 at 5:24 PM João Távora <joaotavora@gmail.com> wrote:
>
> > 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)?
>
> Notification, request and response maps to events, request and
> response. The biggest difference might be the reverse request
> but that could be implemented as an notification/event in a pinch.

If I understand correctly, reverse requests _are_ supported in JSONRPC.
Can you give a short example transcript illustrating such a conversation?

> There are two things that can be a bit of a challenge, maybe:
> - DAP servers are not that well behaved in general, with a pipe
>   connection they like to use std out as they please (none DAP
>   messages).

Meaning they put non-JSON cruft in the stdout as well?  Not great, but
not dramatic, I guess  as long as they don't do it in the middle of the
message right?

Again, helpful if you could attach a stdout dump of a conversation
where some of this takes place.

> - I don't know its a dape problem or not but it's not that hard to
>   provoke some servers to send broken messages if they user chooses to
>   continue the execution while the server is in the middle of responding

OK.  Then in your opinion what is the easiest (and or most representative)
DAP server to start playing with?  Hopefully some C/C++ one, but feel
free to suggest another.

> This means that the parsing needs to do some cleanup during.
>
> > 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?
>
> More then happy to offload some of the work ;) I think that would
> greatly improve the performance and stability of dape to reuse some
> well tested software. I also thin that dape might be able to reuse
> some parts of eglot, the repl completion for example, I don't know
> what the way forward would be for that.

Extract parts of eglot.el into a reusable library, I guess.

But yes, I would be very glad to see DAP dape.el become the DAP
coutnerpart to LSP eglot.el, with most analogous abstractions
having analogous interfaces.  Happy to change eglot.el
significantly to make that happen (backward-compatibility
permitting, of course).

João