Use eglot--dbind for destructuring

[mkcms]

• eglot.el (eglot--lsp-interface-alist): Add CodeAction,
  TextDocumentEdit, WorkspaceEdit.
  (eglot--apply-workspace-edit): Use eglot--dbind.
  (eglot-code-actions): Use eglot--lambda.

[mkcms]

@joaotavora You mentioned that eglot--lsp-interface-alist should only contain types "designated by the spec as export interface. " Is there a reason for it? What does the export keyword mean in TS?

AFAICS, most interfaces are not exported.

[mkcms]

I couldn't find any more uses of export interface.

[joaotavora]

@mkcms This looks good, and by the way, is the way I would like to see it merged (adding interface specs little by little, and using eglot--dbind with no formal interface here and there).

The only thing that I am considering reviewing is the eglot--dbind interface. I think we don't need the &key at all. And I also think that the interface spec could be inside the formal arg list, but in a sublist in the first position. So

(eglot--dbind (foo bar baz) obj ...)

Would do what (eglot--dbind nil (&key foo bar baz) obj...) does now. And

(eglot--dbind ((TheFoo) foo bar baz) obj ...)

Would do what (eglot--dbind TheFoo (&key foo bar baz) obj ...) does now.

What do you think?

Regarding export interface, I'll have a second look. I looked at a few and found that, so assumed most important external interfaces would be like that... But it's not crucial, I think. I don't know exactly what format/informal language the spec is built upon, but it smells vaguely of C# or Java or something.

[mkcms]

What do you think?

Looks good, I also wanted to propose getting rid of &key because it's redundant and because when implementing the pcase macro, it was complicating things.

[joaotavora]

Regarding the pcase implementation, I wanted to say that it is only that, an implementation. I think I shall move forward with a pcase-less eglot--dcase. Then, when we have the pcase implementation, we can probably try fancier things like.

(eglot--dbind ((or FooObject NearFooObject) foo bar baz) obj ...)

Or something like that. Or even use pcase directly.

[mkcms]

Regarding the pcase implementation, I wanted to say that it is only that, an implementation. I think I shall move forward with a pcase-less eglot--dcase. Then, when we have the pcase implementation

Sorry, I don't understand, should I ditch the pcase PR?

[joaotavora]

Sorry, I don't understand, should I ditch the pcase PR?

No. It's just that it's not really ready yet. (for example, it uses eval, which is generally sign of problems).

So I'm going to do a simpler eglot--dcase for now. And then we can upgrade to pcase which could (probably should) make eglot--dcase obsolete.

[mkcms]

No. It's just that it's not really ready yet. (for example, it uses eval, which is generally sign of problems).

OK. Do you have a suggestion what I should use instead? I couldn't find anything in the Emacs sources for dynamic macro expansion.

[joaotavora]

OK. Do you have a suggestion what I should use instead? I couldn't find anything in the Emacs sources for dynamic macro expansion.

Macros are a black art (I'm not particularly good at them). But once you understand the macroexpander you should be able to generate code at macroexpansion-time without ever using eval. Here's what helps me think. Everytime the macroexpander looks at a top level form of a macro that it knows, it writes in the macroexpansion. That macroexpansion can use variables, functions, other macros, that are available at macroexpansion time (which is quite different from run-time, or even before the file is loaded).

I'm sorry if I can't be more help. If you write Stefan Monnier and explain the problem (or write to emacs-help with CC: to him), I'm sure he will help you with your problem.

Anyway, as promised, I pushed a preliminary version (possibly buggy) of an eglot--dcase macro. We should make that our interface, and vary the implementation to pcase once it's ready.

[joaotavora]

Merged this after updating to the new eglot--dbind protocol.

[mkcms]

@joaotavora So what about interfaces which are not export interface?

[joaotavora]

@joaotavora So what about interfaces which are not export interface?

They could be added to eglot--lsp-interface-alist as well, I guess. I haven't yet understood what the difference is between an export an non-export interface.