I think I found a bug: code action failure

[refaelsh]

Here is a screenshot:

As you can see, there is a suggested code action on that line. I do eglot-code-actions and get this surprising question:

Usually it never asks this question on a code action, the question happens only rarely. Don't know how to reproduce.
When I press y, nothing happens except the question changes color to white:

Please help :-)

[refaelsh]

Here is a screenshot of the eglot-events-buffer function:

[manuel-uberti]

Again, can you go through this to report a possible bug: https://joaotavora.github.io/eglot/#Troubleshooting-Eglot?

I am not linking that page again to annoy you, it's just that for the maintainer of this project to be able to investigate reports they need to be useful in order to make it simple to verify any problematic behaviour.

[refaelsh]

Include a description of how the maintainer should obtain, install, and configure the language server you used. Maintainers usually have access to GNU/Linux systems, though not necessarily the distribution that you may be using. If possible, try to replicate the problem with the C/C++ or Python servers, as these are very easy to install.

The LSP in question is haskell-language-server.

Describe how to setup a minimal project directory where Eglot should be started for the problem to happen. Describe each file’s name and its contents. Alternatively, you can supply the address of a public Git repository.

The repo is here: https://gitlab.com/refaelsh/giter (bbc85df0). File name is /src/Shell/FileSystemWatcher.hs, line number 23.

Include versions of the software used. The Emacs version can be obtained with M-x emacs-version.

Emacs 28.2, Eglot 1.15.

Anything I missed?

[joaotavora]

Anything I missed?

Yes :-) there are 7 points in total and you only answered 3.

We need a "minimum reproducible recipe", or else I can't be of much help. I can tell you though, that it seems/smells like a server problem. But I can't be sure yet.

From your screenshots you have a lot of extra configuration. For a bug report to be efficient and lead to a conclusive, we need all that configuration to be temporarily removed, and that's what the 7 points is about. If you read them closely.

Regarding the confirmation of the code action, look up the documentation on eglot-confirm-server-initiated-edits: https://joaotavora.github.io/eglot/#index-eglot_002dconfirm_002dserver_002dinitiated_002dedits

[refaelsh]

Regarding the confirmation of the code action, look up the documentation on eglot-confirm-server-initiated-edits: https://joaotavora.github.io/eglot/#index-eglot_002dconfirm_002dserver_002dinitiated_002dedits

Why is that on by default. In Neovim's built-in LSP it is off by default. That's why it seems strange to me.

Yes :-) there are 7 points in total and you only answered 3.

Understood. I will do it asap.

We need a "minimum reproducible recipe", or else I can't be of much help.

Yes, completely understandable.

[joaotavora]

Why is that on by default?

When I created it, I thought it would be a good default, since I wanted to know in advance how many buffers/files the server was going to modify silently.

Now that it's the default, I willing to bet that at least users like it. So changing it is tricky, but we can try. You can follow bug 60338 for a related discussion.

In Neovim's built-in LSP it is off by default. That's why it seems strange to me.

I didn't try Neovim LSP before, as I don't use vim and possibly it didn't exist.

[refaelsh]

Here is a screenshot of the eglot-events-buffer function:

Do you know what this cryptic error means?

[joaotavora]

Yes, the server says it wants to edit a document, but it says it wants to edit an older version of the document, one that Eglot thinks is no longer current. So Eglot refuses to apply the edit, which is the correct thing to do.

Who is wrong here? The server, who thinks the current version is 0 or Eglot, who thinks the current version is 1? We can't know unless you follow the steps. Perhaps just attaching the full events log would clear it up. Do not attach as screenshots though. Use text.

[refaelsh]

Perhaps just attaching the full events log would clear it up.

Until I follow all the 7 steps, I wanted to attach, as text, the full events log, but the issue stopped reproducing.
Bummer.

I was wandering, could it happen because of one of the following reasons?
1.
** Detect file change outside of Emacs
#+begin_src emacs-lisp
(global-auto-revert-mode 1)
(setq global-auto-revert-non-file-buffers t)
#+end_src
2.
** Undo history persistence
#+begin_src emacs-lisp
(use-package undohist
:config
(undohist-initialize))
#+end_src

Maybe thos options somehow confuse Emacs/Eglot into seeing different versions of the file?

[joaotavora]

but the issue stopped reproducing. Bummer.

If the issue has stopped, that's good :-) If it comes back again. Collect the text log then.

I was wandering, could it happen because of one of the following reasons?

I'd say not, but everything is possible, I can't guess. That's why a bug reproduction recipe is necessary. Take your time.

[refaelsh]

You can follow bug 60338 for a related discussion.

I love popcorn!

P.S.
I eventually found "Not easy at all to upgrade :core packages like Eglot" and it was a very interesting read. It took two evenings and lots of popcorn, but I've read it all.

[refaelsh]

If the issue has stopped, that's good :-) If it comes back again. Collect the text log then.

Until it comes back, I think I will close this.

[refaelsh]

TL:DR; Its a bug in haskell-languge-server.

I should have searched open issues before asking here. Sorry for wasting your time.
Here is what I found: #1051.