search

flycheck / flycheck-eglot

Flycheck support for eglot
GNU General Public License v3.0
32 stars 3 forks source link

Missing code actions #6

Open AgrYpn1a opened 5 days ago

AgrYpn1a commented 5 days ago

Hey, I am unable to configure Eglot to display code actions such as import fixes with Flycheck. Any suggestions? Here's a link to my current config:

intramurz commented 3 days ago

Hi!

Could you clarify the context please? For example, if you set the point to an error in the source code buffer and M-x eglot-code-actions, you expect to get code actions relevant to that error. (It works? This should not concern flycheck at all). And in what context and what doesn’t work, and how it supposedly should?

I looked at your config and it seems to work quite well. Just note that lines 39-41 are not needed, since flycheck-eglot does it itself, and there is a typo in line 43, but all this should not affect anything.

AgrYpn1a commented 3 days ago

Hey, the context is as you mentioned. When I put the cursor under the highlighted error (for example, the most usual case being the missing imports) it should suggest the code actions to auto import. For some reason, in my previous configuration where I have used flymake instead of flycheck this has worked. I know it doesn't make sense, but could flycheck be somehow interfering with with eglot in a way that it prevents it from working correctly?

AgrYpn1a commented 3 days ago

Apparently, Eglot sends different kind of information to the lsp based on whether Flycheck or Flymake is enabled, here's the difference:

https://gist.github.com/AgrYpn1a/1df621bba55e411cb1261df86ebec82b

intramurz commented 1 day ago

Thanks for the research and detailed information; this is really interesting. Looks like you found a tricky bug.

Yes, you were right, eglot-code-actions do indeed depend on (implicit) context, but not on flycheck, but on flymake (or the lack thereof 🙂). Eglot under the hood passes diagnostics back from flymake to the LSP server. No flymake - no diagnostics. I don’t quite understand the meaning of this cycle, since this diagnostic already comes from the LSP server. At least some LSP servers seem to ignore it; since there code actions work well with flycheck. If the root of evil is really in that diagnostics, I hope to fix it soon. Short code examples that cause this behavior would be very welcome.

(Grumbling) I don't think it's good design to have two different packages so tightly coupled that eglot can't work properly without flymake. However, we have to work as is.