Limitation when calling code actions non-interactively from hooks. (Was: Regression in code action - "source.organizeImports")

[dunric]

Used to call eglot-code-action-organize-imports for my Go(lang) gopls sessions in a hook at buffer save. Now it fails with

eglot--error: [eglot] No "source.organizeImports" code actions here

It did worked before, like invoking gopls imports on file manually.

I've tried revert gopls to older version 0.16.0 but getting the same error.

It looks like a regression in eglot or even emacs to me.

Package eglot is built-in.
Status: Built-In.
Version: 1.12.29

[joaotavora]

OK. There's a lot missing here. If this is a regression, I presume you can pinpoint an eglot version where this worked. And the "this" must be impeccably specified: use an emacs -Q session perhaps, as described here: https://joaotavora.github.io/eglot/#Reporting-bugs-1

Pay close attention to step 6.

[dunric]

@joaotavora Thanks for the heads up.
Unfortunately I'm now too busy to dig deeper into that issue. I've tried stripped down Emacs instance as suggested and the issue persists.

I've figured out, it has to do with error handling of eglot-code-action kind of functions.
When "source.organizeImports" action is called on a buffer which has imports already "organized", eglot function throws an error and when called in a hook, it stops its execution prematurely.

Now I worked around this with explicitly ignoring errors like

(add-hook 'before-save-hook
  (lambda ()
    (ignore-errors (eglot-code-action-organize-imports 1))
    (eglot-format-buffer))
  -10 t)

[joaotavora]

When "source.organizeImports" action is called on a buffer which has imports already "organized", eglot function throws an error and when called in a hook, it stops its execution prematurely.

I see. That makes sense. I should try to find a way to fix that perhaps.

Are you sure it's really a regression between Eglot versions? Or could it be it's something that you didn't notice until you had one of this "already organized" files?

[dunric]

Are you sure it's really a regression between Eglot versions? Or could it be it's something that you didn't notice until you had one of this "already organized" files?

It did worked before, based on setup suggested by gopls docs. However in the meantime I made several changes in my Emacs environment and worked on different projects. When I came back to Golang I've noticed described problem. So, I'm not 100% sure Eglot is the cause. Previous function may have been caused coincindentally of different configuration and other packages combination. I could trace it within my dotfiles git log, but definitely not now, maybe later.

[joaotavora]

I could be that in previous gopls versions it always reported the code action even if there was nothing to do, and now it doesn't. Anyway, I'm pingin @adonovan who's on the Go team @ Google, i think.

[adonovan]

I'm not aware of any relevant recent changes in gopls here. Using the latest gopls, the organize-imports code action is offered only when there is work to do, as this session shows:

$ ls
foo.go

$ cat foo.go 
package main

import (
	"fmt"
	"log"
)

func main() {
	fmt.Println("hello")
}

$ gopls codeaction ./foo.go 
edit	"Organize Imports" [source.organizeImports]
command	"Browse gopls feature documentation" [gopls.doc.features]
command	"Browse documentation for package main" [source.doc]

$ gopls codeaction -kind=source.organizeImports -exec -write ./foo.go 
foo$ cat foo.go 
package main

import (
	"fmt"
)

func main() {
	fmt.Println("hello")
}

$ gopls codeaction ./foo.go 
command	"Browse gopls feature documentation" [gopls.doc.features]
command	"Browse documentation for package main" [source.doc]

$ 

[joaotavora]

Using the latest gopls, the organize-imports code action is offered only when there is work to do, as this session shows:

OK. But was it always like this?

Regardless, this should probably be fixed in Eglot, but to do it cleanly requires a breaking change to how code actions are invoked non-interactively. There was some other issue also requesting changes to code actions. I'll try to dig it up.

[joaotavora]

There was some other issue also requesting changes to code actions. I'll try to dig it up.

In this issue #1409, @stapelberg is requesting something fairly related, which is the ability to more easily add this import organization to the save hook (and other hooks).

I'm not fully onboard with Michael's idea over there, but I see that this code action is very important to Go people, and I'm receptive to the idea of making an argless, non-interactive call to code action functions like eglot-code-action-organize-imports default to the whole buffer.

And of course, we should make it so that it swallow the error if the code action isn't available is this issue.

If someone wants to work on this, this must all be done in eglot--code-action , and eglot-code-actions, the function. The current macro is fishy: it always assumes the call is interactive:

(defmacro eglot--code-action (name kind)
  "Define NAME to execute KIND code action."
  `(defun ,name (beg &optional end)
     ,(format "Execute `%s' code actions between BEG and END." kind)
     (interactive (eglot--code-action-bounds))
     (eglot-code-actions beg end ,kind t)))  ;; <--- this last t assumes the function is always called interactive, not true.

(eglot--code-action eglot-code-action-organize-imports "source.organizeImports")
(eglot--code-action eglot-code-action-extract "refactor.extract")
(eglot--code-action eglot-code-action-inline "refactor.inline")
(eglot--code-action eglot-code-action-rewrite "refactor.rewrite")
(eglot--code-action eglot-code-action-quickfix "quickfix")