all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Troy Brown <brownts@troybrown.dev>
Cc: Jeremy Bryant <jb@jeremybryant.net>, 71642@debbugs.gnu.org
Subject: bug#71642: 30.0.50; eglot-execute doesn't support ExecuteCommandParams
Date: Thu, 20 Jun 2024 10:46:38 +0100	[thread overview]
Message-ID: <CALDnm52HBHu-ifPgFHfxinB=KGaetuoVobM4WVyVx+0JBnb8_g@mail.gmail.com> (raw)
In-Reply-To: <CABvCZ42Efgj7ANsttot0UyeORy=xaM5iF6A=thtCRSiFgJq2TA@mail.gmail.com>

On Thu, Jun 20, 2024 at 4:55 AM Troy Brown <brownts@troybrown.dev> wrote:
>
> On Wed, Jun 19, 2024 at 6:26 PM João Távora <joaotavora@gmail.com> wrote:
> >
> > Troy, you seem to be on to something.  It would seem Command shouldn't
> > be there in the dcase matcher in eglot-execute at all.  Instead
> > ExecuteCommandParams should be there.
> I suspected that might be the case (that Command was really supposed
> to be ExecuteCommandParams), but I hadn't exhaustively looked at
> everything, however you have now confirmed that suspicion.

No, no, after closer analysis, this is not right.  Command must
absolutely be there in the matcher, as textDocument/codeAction
can simply return an array of them.

> > I may just have been thrown off  by the confusing naming (naively
> > thinking that executeCommand executes Commands, but it doesnt).
> Yes, that makes sense, I was confused for a bit as well until I had
> investigated why it had the "title" parameter, looked at the LSP
> specification and realized that it was meant for something else.

On closer analysis the only confusing thing is that the spec
encourages clients to call textDocument/executeCommand with
illegal ExecuteCommandParams objects that contain an extraneous
'title'

Most servers apparently don't care, but Eglot is doing this and
it's a subtle bug.

I think the right thing to do is to have Command _and_
ExecuteCommandParams in the matcher.

After that:

* custom callers of `textDocument/executeCommand` can do their thing
   (they could already but now it's arguably easiest)
* Eglot won't suffer from this subtle bug
* Hopefully the situation is clearer

While none of this is super-serious, I think we can fix it and
we'll benefit in clarity.

> Since
> eglot-strict-mode doesn't normally contain disallow-non-standard-keys,
> it causes eglot--dcase to match ExecuteCommandParams for a CodeAction
> interface if the optional "command" parameter is present.

But if it is present, it shouldn't be a string, so it should still
work in the order.

I've done a tweak to your patch.  See after my sig.  It's untested, so
please have a look. If you can, test, add more comments, change the order
if indeed it's needed.  You can also change the implementation if you think
the recursiveness makes it more confusing.

When that is done, please resubmit the patch with the nicely formatted
commit message (just like you did before) and I'll ask someone to
install it (or install it myself).

João

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 6896baf30ce..450f5a507f6 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -631,6 +631,7 @@ eglot--uri-path-allowed-chars
                              :command :data :tags))
       (Diagnostic (:range :message) (:severity :code :source
:relatedInformation :codeDescription :tags))
       (DocumentHighlight (:range) (:kind))
+      (ExecuteCommandParams ((:command . string)) (:arguments))
       (FileSystemWatcher (:globPattern) (:kind))
       (Hover (:contents) (:range))
       (InitializeResult (:capabilities) (:serverInfo))
@@ -891,17 +892,25 @@ eglot-execute-command

 (cl-defgeneric eglot-execute (server action)
   "Ask SERVER to execute ACTION.
-ACTION is an LSP object of either `CodeAction' or `Command' type."
+ACTION is an LSP `CodeAction', `Command' or `ExecuteCommandParams'
+object."
   (:method
    (server action) "Default implementation."
    (eglot--dcase action
-     (((Command)) (eglot--request server :workspace/executeCommand action))
+     (((Command))
+      ;; Convert to ExecuteCommandParams and recurse (bug#71642)
+      (cl-remf action :title)
+      (eglot-execute action))
+     (((ExecuteCommandParams))
+      (eglot--request server :workspace/executeCommand action))
      (((CodeAction) edit command data)
       (if (and (null edit) (null command) data
                (eglot-server-capable :codeActionProvider :resolveProvider))
           (eglot-execute server (eglot--request server
:codeAction/resolve action))
         (when edit (eglot--apply-workspace-edit edit this-command))
-        (when command (eglot--request server
:workspace/executeCommand command)))))))
+        (when command
+          ;; Recursive call with what must be a Command object (bug#71642)
+          (eglot-execute command)))))))

 (cl-defgeneric eglot-initialization-options (server)
   "JSON object to send under `initializationOptions'."





  reply	other threads:[~2024-06-20  9:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-19  3:24 bug#71642: 30.0.50; eglot-execute doesn't support ExecuteCommandParams Troy Brown
2024-06-19 21:19 ` Jeremy Bryant via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-19 22:26   ` João Távora
2024-06-20  3:55     ` Troy Brown
2024-06-20  9:46       ` João Távora [this message]
2024-06-21 12:14         ` Troy Brown
2024-06-21 13:51           ` João Távora
2024-06-22  8:44             ` João Távora
2024-06-22  9:48               ` Eli Zaretskii
2024-06-23 14:27                 ` Troy Brown
2024-06-23 14:35                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALDnm52HBHu-ifPgFHfxinB=KGaetuoVobM4WVyVx+0JBnb8_g@mail.gmail.com' \
    --to=joaotavora@gmail.com \
    --cc=71642@debbugs.gnu.org \
    --cc=brownts@troybrown.dev \
    --cc=jb@jeremybryant.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.