Corfu + Eglot: LSP server gets out of sync

[yalfg]

[EDIT 2 by @joaotavora: The sync problem is hard to reproduce but not impossible. We believe it has been fixed 100% according to this comment. Other incompatibilities remain, but they have workarounds in Corfu's website. ]

[EDIT 1 by @joaotavora: This problem is hard to reproduce and it's not worth investigating. Corfu is inherently unsuitable for usage with Eglot, as demonstrated here https://github.com//discussions/1127#discussioncomment-5431683. Until that bug is fixed, strongly recommend company is used instead. It has flawless CAPF support ]

---

This is to discuss an issue raised on reddit: https://old.reddit.com/r/emacs/comments/z8wxi7/help_tracking_down_eglot_or_flymake_issue/

I tried and failed reproducing this issue, it's not deterministic. It seems timing dependent. But as other people seem to see it it seems worth discussing here.

When using eglot sometimes the LSP server gets out of sync, with the result that it reports non existing errors through flymake or invalid completions. This seems related to completion, as it subjectively follows completion proposals (there is no need to accept them, the issue happen when ignoring the completion UI).

It does not seem related to the LSP server: it happened with both Python and several versions of clangd to me.

It seems related to the completion framework, and timing. In particular how much work happens for completion. In my case:

• No issue with company as completion UI;
• Issues quite frequent and noticeable with a bare corfu set-up;
• When adding completion sources (dabbrev, yasnippet through cape) the issue becomes extremely rare in my case.

When the LSP server gets out of sync, which seems to be after some completion activity, the Emacs buffer content is correct.

Restarting and reconnecting to the eglot server solves the issue.

I though it was a weirdness in my environment but the reddit submission shows it's not. As I said, I failed finding a way to reproduce this in a deterministic way. But I'd be open to try some instrumentation if it helps solving this issue.

I'll point the reddit submission to this discussion so other people can help.

And BTW, thansk for eglot, it rocks! ;)

[joaotavora]

Thanks. These are the bugs i fear, but also those that i want to catch. Ideally, we'd need a reproduction recipe. Perhaps there's a little more effort that can be put in? It seems to be correlated with Corfu. I use company and those servers daily without problems. But it could be something else. Like Eglot, Emacs itself, something else in your config.

Even without a deterministic recipe, it would be good to narrow this down to a specific source file that you could share and some minimal config (Emacs + Corfu + Eglot).

[sudo-human]

I have a relatively simple eglot config.

  :bind (("C-c l e" . eglot)
         :map eglot-mode-map
         ("C-c l r" . eglot-rename)
         ("C-c l a" . eglot-code-actions)
         ("C-c l f" . eglot-format))
  :custom
  (eglot-autoshutdown t)
  :init
  (which-key-add-key-based-replacements "C-c l" "eglot")
  :config
  (setcdr (assq 'java-mode eglot-server-programs)
          `("jdtls" "-data" "/home/pr09eek/.cache/emacs/workspace/"
	    "-Declipse.application=org.eclipse.jdt.ls.core.id1"
	"-Dosgi.bundles.defaultStartLevel=4"
	"-Declipse.product=org.eclipse.jdt.ls.core.product"
	"-Dlog.level=ALL"
	"-noverify"
	"-Xmx1G"
	"--add-modules=ALL-SYSTEM"
	"--add-opens java.base/java.util=ALL-UNNAMED"
	"--add-opens java.base/java.lang=ALL-UNNAMED"
	"-jar ./plugins/org.eclipse.equinox.launcher_1.5.200.v20180922-1751.jar"
	"-configuration ./config_linux")))

Corfu config:

  ;; Optional customizations
  :custom
  (corfu-cycle t)                ;; Enable cycling for `corfu-next/previous'
  (corfu-auto t)                 ;; Enable auto completion
  (corfu-auto-prefix 1)
  (corfu-separator ?\s)          ;; Orderless field separator
  (corfu-quit-at-boundary t)   ;; Never quit at completion boundary
  (corfu-quit-no-match 'separator)      ;; Never quit, even if there is no match
  (corfu-preview-current nil)    ;; Disable current candidate preview
  (corfu-preselect-first nil)    ;; Disable candidate preselection
  ;; (corfu-on-exact-match nil)     ;; Configure handling of exact matches
  ;; (corfu-echo-documentation nil) ;; Disable documentation in the echo area
  (corfu-scroll-margin 5)        ;; Use scroll margin

  ;; Enable Corfu only for certain modes.
  ;; :hook ((prog-mode . corfu-mode)
  ;;        (shell-mode . corfu-mode)
  ;;        (eshell-mode . corfu-mode))

  ;; Recommended: Enable Corfu globally.
  ;; This is recommended since Dabbrev can be used globally (M-/).
  ;; See also `corfu-excluded-modes'.
  :init
  (global-corfu-mode))

;; Add extensions
(use-package cape
  :init
  ;; Add `completion-at-point-functions', used by `completion-at-point'.
  (add-to-list 'completion-at-point-functions #'cape-dabbrev)
  (add-to-list 'completion-at-point-functions #'cape-file)
  ;;(add-to-list 'completion-at-point-functions #'cape-history)
  ;;(add-to-list 'completion-at-point-functions #'cape-keyword)
  ;;(add-to-list 'completion-at-point-functions #'cape-tex)
  ;;(add-to-list 'completion-at-point-functions #'cape-sgml)
  ;;(add-to-list 'completion-at-point-functions #'cape-rfc1345)
  ;;(add-to-list 'completion-at-point-functions #'cape-abbrev)
  ;;(add-to-list 'completion-at-point-functions #'cape-ispell)
  ;;(add-to-list 'completion-at-point-functions #'cape-dict)
  ;;(add-to-list 'completion-at-point-functions #'cape-symbol)
  ;;(add-to-list 'completion-at-point-functions #'cape-line)
  )

(use-package kind-icon
  :after corfu
  :custom
  (kind-icon-default-face 'corfu-default) ; to compute blended backgrounds correctly
  :config
  (add-to-list 'corfu-margin-formatters #'kind-icon-margin-formatter))

I'm also facing the same issue since I moved to eglot + corfu setup. I'll also try out this with a bare config and see If I'm able to reproduce this issue.

[AustinMooreT]

My config is almost identical to @ps-143. I tend to get this error a lot. Are there any specific functions or variables I could start looking at while coding with debug enabled to help pinpoint what's going on and maybe make this reproducible? I know that's probably a big ask since we don't know what's happening. I plan to start digging around over the weekend to maybe try and figure out how to make this happen every time.

[joaotavora]

I have a relatively simple eglot config.

Relative indeed :). I can't try it this cape stuff and all those bindings and customization. And installing a java toolchain is also a problem. I'm looking for something like:

emacs -Q -L path-to-corfu -l corfu -f whatever-enables-corfu foo.cpp -f eglot

Where the clangd server is assumed to exist in PATH. And then the contents of the foo.cpp file and some instructions for monkeying around until the problem happens.

[sudo-human]

🤣 my config is mostly copied from the corfu's readme. Let me try what you are suggesting, but I'm new to emacs and I don't understand all the options that you have specified here. I'll look it up and try to help here.

[joaotavora]

No problem. -l is shorthand for load, meaning that it will load the corfu.el library that is in the load path as you just used -L to add it before. -f whatever-enables-corfu is a just a function call to whatever-enables-corfu, I suppose it should be global-corfu-mode. ( I also suspect all those corfu settings like corfu-auto-prefix aren't strictly necessary for reproducing the bug, but you can set them later if it turns out to be necessary). foo.cpp is the file that you want Emacs to visit right away. It could be a python file if you have that and a python server handy. Finally -f eglot starts up Eglot. So, all you have to do now is to edit around in the file and request corfu completions and keep an eye out for the bug.

[joaotavora]

For those users looking to debug this themselves, look in the *events* buffer for the textdocument/didChange notification that Eglot sends the server. The details of that didChange notification can be found here https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didChange

The notification's content should explain to the server what every little edit does, including edits done by a completion system such as company or corfu. After selecting a legitimate corfu completion, corfu will insert some text into the buffer. This will trigger the normal Emacs hooks called before-change-functions and after-change-functions, and those are where Eglot has setup tracking so that it can build the next textdocument/didChange notification. Presumably, somewhere along the line, this fails and Eglot reports something to the server that doesn't quite describe what really happened in the buffer. Thus the server's view of the "opened text document" (LSP parlance for "buffer") gets out of sync with what's really there.

[jdtsmith]

I've also seen this on occasion with corfu & pyright LS; eglot-reconnect always fixes it. I do note that corfu places candidates in the buffer as a normal part of previewing completion, which is different than company. So it will generate more buffer changes. So far I haven't seen any textDocument/didChange issues while playing with corfu completion, but then again I haven't experienced the sync drift again since looking either. Will keep an eye out.

[Cerebus]

Personally I see it most with corfu, go-mode, and gopls.

[jdtsmith]

Can you make it recur pretty quickly?

[joaotavora]

I do note that corfu places candidates in the buffer as a normal part of

previewing completion, which is different than company.

So it will generate more buffer changes.

Oof, really? So corfu changes the buffer to show all candidates and then undoes it? That is indeed "dangerous". That means there can be a transient time where the buffer's are completely nonsensical. It _could_ work if the undo is done carefully (and I use regular undo all the time with no de-sync issues), but if it's not then it's a good bet the problem lies there. My bet is that corfu will try to hide these changes from normal "undo". That would be reasonable otherwise C-_ would recover that nonsensical state. But it must not hide these changes from Emacs modification hooks unless it is doing so in bullet-proof fashion.

So far I haven't seen any textDocument/didChange issues while playing

with

corfu completion, but then again I haven't experienced the sync drift

again

since looking either. Will keep an eye out.

So have you or have you not seen this with corfu? You first sentence seems to indicate you have.

[jdtsmith]

False alarm. In fact corfu uses a 'display overlay to preview candidates in buffer. I had mistakenly thought this was generating didChange events, but checking again, it isn't. Just to be sure, for people who are experiencing this quite often, check the variable:

corfu-preview-current is a variable defined in ‘corfu.el’.

Its value is ‘insert’

Preview currently selected candidate.
If the variable has the value ‘insert’, the candidate is automatically
inserted on further input.

Try setting it to nil to see if the problem persists (my guess: it does). For me this is happening only couple times a week max.

since looking either. Will keep an eye out.
So have you or have you not seen this with corfu? You first sentence seems
to indicate you have.

Yes, I have seen it, but it's rare for me, and hasn't recurred in the last day since I've been looking for issues with the didChange.

[jdtsmith]

For those of you trying to debug this, I've written a small test framework that makes following the didChange events less sanity-taxing. Just M-x eglot-report-didChange-setup in the events buffer and the giant event stream will be parsed to something like this (with green for additions, red for deletions):

So far I've noticed that after corfu completes and inserts something in the buffer, the deletion of the original text fragment being completed comes after the insertion of the new candidate (e.g. at the end of this example, I inserted RuntimeWarning from eglot/pyright's suggestions). I'm not sure if that really matters, since presumably the insertion moves the fragment over prior to deleting.

For people who can get the sync issue to appear quickly, keep track of what you are doing and then look in the didChange logs at the time the issue appears.

[Cerebus]

I saw this happen with gopls just now. I thought I was running your diagnostic, but I'd restarted emacs and forgot to reset it. I'll make sure I get an event trace next time.

The LSP was reporting a single character at the end of the line (IME this is typical, but not exclusive), and I was able to clear it (and get gopls back into sync) with a delete-forward-char through the newline and then re-adding the newline. So it definitely seems related to corfu's insert-then-delete.

It seems to me I have to be moving pretty fast for this kind of error to appear, which may be why it's so persnickety to reproduce.

[jdtsmith]

I just updated my gist, please grab again; it had an intermittent bug that caused some repeated entries. Note: you can run M-x eglot-report-didChange-setup after the fact in the events buffer and it works just as well. I in fact just saw the desync happen but foolishly did not stop immediately to diagnose.

[jdtsmith]

Anyone make progress on this? AFAIU, corfu expects CAPF backends can be cleanly interruptible with while-no-input. It's possible corfu is interrupting eglot's CAPF between when it notices buffer changes and reports them. But presumably the on-change code isn't being called from the CAPF, so it really shouldn't be the case. @minad may have more thoughts.

[ndryden]

I don't have a clear idea what's going wrong, but I wanted to chime in to say that I've also seen this behavior, and that it is especially common for me when editing files with Tramp. I was able to narrow things down some: I've only seen the issue when I have corfu-auto enabled. Additionally, wrapping that with cape-wrap-noninterruptible seemed to fix the issue, so this is weak evidence that it's an interruption issue.

[ville-h]

Is there a function to call that would reset eglot+clangd state back to working state? Right now I just close the buffer and open it again manually, but that's a bit annoying as I'm hit by eglot+clangd going out of sync tens of times every day.

[joaotavora]

I did. Can't say it was unhelpful, but also didn't really go anywhere useful.

Hmmm, not very useful indeed. It seems corfu pull this concept of "interruptible capfs" out its ass of thin air and then requires all capfs to behave like that. And the home page even boasts of following the protocol. I don't know what "interruption" the author is talking about, there's no explanation.

If I had a concrete idea maybe I could do something about it, or show other ways around, but I don't. Eglot works fine with company and any other completion backends.

[psethwick]

It's rare I think, but even wrapped with the "don't interrupt" advice I think it still happened, so I think perhaps it is something else.

[joaotavora]

Yes, I've been looking at this too, and "interruptible" could be just a while-no-input call there. I think that's fine, there's no problem with Eglot there.

I'm looking at corfu's group amalgamation code.

I haven't been able to trigger the bug yet. How exactly can you trigger this more or less reliably?

[ville-h]

I've no specific steps to reproduce. As I program it becomes obvious the red squigglies in the buffer are there in error. Not that I've an error in the code, but some kind of state has gotten out of sync. Happens several times per hour for me. Perhaps some languages are more susceptible to this than others. I notice this behaviour when programming c++.

I am not a lisp programmer so I can't implement this my self, but perhaps someone could provide a mechanism to do a "recording" that can be saved to a file. I don't know emacs internals well enough to really say what should be recorded. I can then add such function to my restart eglot binding and start sending those over.

[joaotavora]

@jdtsmith has already implemented this. See #1127 (comment) and there's already the M-x eglot-events-buffer anyway.

[joaotavora]

This analysis from @jdtsmith seems useful. I'm paying more attention to it.

So far I've noticed that after corfu completes and inserts something in the buffer, the deletion of the original text fragment being completed comes after the insertion of the new candidate (e.g. at the end of this example, I inserted RuntimeWarning from eglot/pyright's suggestions). I'm not sure if that really matters, since presumably the insertion moves the fragment over prior to deleting.

[joaotavora]

I've reproduced this specific quirk, though I don't know if this any any effect.

Using @jdtsmith test framework: https://gist.github.com/jdtsmith/535fe465bd0e9704a85e2555d528214a

In a c++ buffer with #include "boost/asio.hpp". First type "asio"
Then type "::" to initiate completion:

With corfu:

16:06->16:06 (1) ":"
16:07->16:07 (1) ":"
16:08->16:08 (1) "a"
16:09->16:09 (1) "r"
16:10->16:10 (1) "e"
16:11->16:11 (1) "a"
16:12->16:12 (1) "d"
16:08->16:08 (14) "•async_read(…)"
16:22->16:27 (5) ""    (deletion)
16:08->16:22 (14) ""   (deletion)
16:08->16:08 (12) "async_read()"
6:00->6:00 (31) "#include \"boost/asio/read.hpp\"\n"

With company:

16:06->16:06 (1) ":"
16:07->16:07 (1) ":"
16:08->16:08 (1) "a"
16:09->16:09 (1) "r"
16:10->16:10 (1) "e"
16:11->16:11 (1) "a"
16:12->16:12 (1) "d"
16:08->16:13 (5) ""   (deletion)
16:08->16:08 (14) "•async_read(…)"
16:13->16:22 (9) ""   (deletion)
16:08->16:13 (5) ""   (deletion)
16:08->16:08 (12) "async_read()"
6:00->6:00 (31) "#include \"boost/asio/read.hpp\"\n"

Both extensions are behaving reasonably in this specific test. I'll try another server to reproduce it.

[joaotavora]

I've reproduced this once or twice in java mode over TRAMP, but it's really hard to reproduce.

I don't think it has anything to do with "interrupts".

This is besides the point, but corfu is not that super, it flickers a lot due to very eager redisplay. At least in the terminal, company behaves much better.

[joaotavora]

I've tried again to reproduce the error consistently so I could analyze it, but I couldn't. It's hard to reproduce. I suspect one of: Corfu's undo management code, it's advice of internal Emacs functions, its forced redisplay calls. Can't say for sure, maybe it's something completely different, maybe just an Emacs bug.

But I've come to the decision that it's not worth trying to fix something that is inherently broken to start with. Corfu is not suitable for any package like Eglot, SLY, CIDER, lsp-mode, that doesn't get the full set of completions from the backend.

Take this example C++ file:

int main() {
  // cursor here
}

Now:

• Try typing std::atomic_ + C-M-i quickly and notice that you might get a completion for std::atomic_bool depending on how fast you type and corfu-auto-delay.
• Try the same thing slower and you'll probably not ever get to std::atomic_bool because the request for completions from the backend is not re-done by corfu.

Do this same exercise of typing slower and faster with company.el and you'll notice you always get to std::atomic_bool.

The synchronization bug is insignificant by comparison, and investigating it is not worth it. Many moons ago there was this very issue in Helm mode. Exactly the same problem, and eventually Thierry fixed it after much discussion. If corfu does the same I can revisit the synchronization bug. Until then no further work is useful here.

emacs-helm/helm#2165

[jdtsmith]

So corfu's author would argue your experiments have revealed a long-standing problem with eglot's CAPF, which company is effectively hiding through its beyond-the-API accommodative approach.

No, it just doesn't make sense. There is no argument here: there is no way you can get sensible completion via LSP without using the "ask every time" strategy. So this should be a "opt-out", not an "opt-in".

Maybe another issue/discussion would be a better place to discuss this, bringing company's and corfu's authors in.

But the counter-argument is that many backends can indeed do more strategic caching, so a UI shouldn't "decide for them". I do agree with you: as I mentioned I don't think you can do any better for a mode like eglot than "ask every time". The question remains though: who should do the asking — the completion UI, or eglot? For that combination, it doesn't really matter who does it, but IMO the arguments for the CAPF table doing the asking-or-caching are stronger than the arguments against.

[joaotavora]

In Emacs, it's very easy to shoot yourself -- or others -- in the foot. Eglot isn't some omniscient divine being with eyes on your computer monitor, it's using before-change-functions and after-change-functions to know about changes to the buffer. If your extension does things like with-silent-modifications, or play around with "undo change groups", or call internal functions or advise them -- all of which corfu does -- you risk breaking those mechanisms and anything relying on them.

I'm not saying any one of these things is at fault here: I don't know. Using them is undoubtedly risky, but they are just suspicions.

I do know this:

• Company works fine, and is pretty snappy, in or outside Eglot. And no "cape" or need to buy in into some tremendous Emacsian oeuvre. Just package-install RET company it
• Eglot's sync code works fine with other buffer changers, completion frameworks, multi-edit code actions, search and replace, fast/slow typing, changes from git, snippets with mirrors, etc etc.

I also know that if someone puts time and effort into writing a reproducible recipe (or at least 1 out of 5 times), perhaps by tweaking timing parameters, then I can look at this. Else, it's just precious hours of my life wasted.

[ndryden]

Just want to clarify something: The suggestion that there is some interrupt issue is not mine, it comes from corfu's author in minad/corfu#283.

I do not have the deep emacs experience needed to contribute to debugging this, but I agree it may be worthwhile to bring corfu's author in: eglot is in emacs core, corfu is rather popular, they should work well together.

[joaotavora]

Understood, @ndryden .

You do not have to have debugging knowledge and analysis skills to be helpful. If you can contribute a sure-fire (or almos) recipe to reproduce this, then that contribution is already very useful.

[jdtsmith]

Eglot isn't some omniscient divine being with eyes on your computer monitor, it's using before-change-functions and after-change-functions to know about changes to the buffer. If your extension does things like with-silent-modifications, or play around with "undo change groups", or call internal functions or advise them -- all of which corfu does -- you risk breaking those mechanisms and anything relying on them.

This is a fair point. If we do get a desync recipe I can try to reengage corfu's author, whom I have worked with. For anyone who sees this issue semi-frequently, try setting corfu-auto to some very short time. In my experience that really stresses CAPF's that communicate with external processes the most.

I echo @ndryden's point that corfu and company should both work with eglot well "out of the box".

[joaotavora]

Maybe another issue/discussion would be a better place to discuss this, bringing company's and corfu's authors in.
But the counter-argument is that many backends can indeed do more strategic caching, so a UI shouldn't "decide for them". I

Backends can do all the caching they want, within their conditions. Eglot's backend does caching :-), just not the caching you would like it to do.

completion-at-point-functions's docstring states quite clearly that

Each function on this hook is called in turn without any argument and
should return either nil, meaning it is not applicable at point,
...
or a list of the form (START END COLLECTION . PROPS), where:
 START and END delimit the entity to complete and should include point,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 COLLECTION is the completion table to use to complete the entity, and
                                                          ^^^^^^^^

Read it again: COLLECTION completes the entity. It doesn't say that COLLECTION should be aware that and remain attentive to anything that can happen in the buffer forever and potentially complete any other thing.

There's no engineering reason for a completion UI (company, corfu, or whatever) to not call the backend function everytime the entity to complete changes in the buffer, which is a decision completely at the UI's discretion. Calling these functions is fast -- or should be -- if they return a closure to to the work, which the majority does.

It's just that 2 years ago someone was magically enlightened to decide that all this which existed before was wrong. And that stance is not worth my time.

[jdtsmith]

Yes this is the same path we were on before, and you highlighted the same word. IMO the docs are unfortunately not at all clear on this point. "Entity" need not mean a fixed and unchanging string of characters but could rather be a "completion target", which would persist not "forever for any future buffer modification", but only and exclusively during one singular completion attempt. The time company or corfu is popped-up, if you will.

I'm not sure you read the arguments I quoted above. But minad is better suited to make the case. He I know is basing his analysis of the CAPF API on a close read of completion-in-region and the emacs-lisp capf.

My opinion: at some level it really doesn't matter which of these views prevail — calling the CAPF again vs. retaining and calling the same completion table lambda. There are some technical differences. For CAPF tables which store their cache in closure variables (which is very convenient), the distinction matters. But you can always cache outside the table lambda.

What does matter, or should matter, is that there needs to be some standard everyone agrees on. I will try to open an issue on that topic exclusively, perhaps on emacs-devel. Eglot is in core, and corfu is in elpa. Both are growing in popularity. IMO, they should work together without special effort.

But I don't think people should be distracted by the API disagreements. We still need a reproducer for this sync issue!

[joaotavora]

Yes this is the same path we were on before, and you highlighted the same word. I

Well, it hasn't changed :-)

but could rather be "completion target",

I guess it could, but it's not, and it never was. It's well defined as the string of characters that exist between START and END (with point in the middle). Your job is to complete that string, i.e. add things to it. When you do that it will become another entity.

which would persist not "forever for any future buffer modification", but only and exclusively during one singular completion attempt. The time company or corfu is popped-up, if you will.

Fortunately, company does not look solely at its own belly button and understands that are other ways to complete things in the buffer, which don't involve the concept of a "session" or a dropdown. The backend shouldn't make assumptions about the form the UI takes.

I'm not sure you read the arguments I quoted above.

I read them :-)

For CAPF tables which store their cache in closure variables (which is very convenient), the distinction matters.

Eglot's CAPF does this. Company calls the inner function frequently, and closure-held cache is made use of, of course, and speeds things up quite a bit. But company calls the outer function again if the entity to complete has changed, as it should.

I'm not against new APIs that solve problems. But here there is no technical problem. Even if this current API is difficult to understand (which I fully agree it is), we still have to maintain it. So there is nothing to gain, no performance or functional advantage, by agreeing on a new protocol, except perhaps the smug feeling that you added more complexity to the world.

[meliache]

I love both Eglot and Corfu and hope we'll find a way to make them work in harmony. There's an overlap in the early-adopters of both packages, as they are used by people who want to have an experience that's more tightly integrated with the Emacs core than LSP-mode or Company (at least that's the promise of those packages). I tried Corfu due to its promise to be basically just a popup and some extras for the built-in Emacs completion, relying on CAPFs and completion-styles. Not sure if I'll use it forever, but I'm thankful for its popularity, that triggered an increased adoption of CAPFs in new packages instead of company-backends, which thus also benefits people using the default completion (even though of course company-capf always worked perfectly fine for me).

When I adopted Corfu I wasn't aware of "disagreements" in the understanding of the CAPF API., I'm not that knowledgeable on a technical level. Sounds to me like the CAPF-documentation could be improved to avoid confusion, but I'm not sure. I don't think that minad had any intent to go against the intended usage of CAPF's or propose new protocols, and definetly I don't think there was malicious intent, so I'd be careful on all sides to keep the discussion friendly and be cautious with attributing intent (see Fundamental Attribution Error).

Maintaining and developing any Emacs packages is a lot of unpaid work and the maintainers don't barely any appreciation back. Therefore I'd like to say that I'm incredibly thankful to people like Joel or Minad for contributing to the Emacs community with their packages 🙏. I also agree that the underlying bug in this issue seems complex and therefore we can't "demand" it to be fixed without providing a reproducible example, so instead of in-depth discussions, that might be the next step (like everyone in this thread seems to agree). Personally, I think I had seen the discussed issues in the past, but never that frequently that they really bothered me.

I agree that ideally the packages should just work together out of the box. But I'd like to note that Corfu has a github wiki that has a section Configuring Corfu for Eglot, which talks about the completion-styles override in Eglot (not sure that's still up-to-date). Temporarily, while the issue is not resolved, I adapted and added the cape-capf-buster advice by @jdtsmith from above to that wiki.

[joaotavora]

more tightly integrated with the Emacs core than LSP-mode or Company (at least that's the promise of those packages).
. I tried Corfu due to its promise to be basically just a popup and some extras for the built-in Emacs completion, relying on CAPFs and completion-styles. Not sure if I'll use it forever, but I'm thankful for its popularity, that triggered an increased adoption of CAPFs

I don't know much about LSP-mode, but Company's "capf" backend is perfectly well integrated with Emacs, APIs. If you try Company with nothing but its company-capf backend, I doubt you'll see much of a difference, except that Company doesn't require a separate package to work on tty Emacs (which IMO is a good thing).

be cautious with attributing intent (see Fundamental Attribution Error).

I'm not attributing intent, but I do note that I see this misleading statement on Corfu's website:

[Company](https://github.com/company-mode/company-mode): Company is a widely used and mature completion package, which 
implements a similar interaction model and popup UI as Corfu. While Corfu relies exclusively on the standard Emacs completion API 
(Capfs), Company defines its own API for the backends. Company includes its completion backends, which are incompatible with the
Emacs completion infrastructure.

The last sentence is misleading. It's true that company includes some of these backends, but its company-capf backend is perfectly well suited for Emacs's completion infrastructure. I once suggested that all the other backends be deprecated. Which would be reasonable. But it's also reasonable to keep them, because they usually don't really hurt anything just by being there, and when they do it's pretty easy to remove them.

I agree that ideally the packages should just work together out of the box. But I'd like to note that Corfu has a github wiki that has a section Configuring Corfu for Eglot, which talks about the completion-styles override in Eglot (not sure that's still up-to-date).

Also misleading. Leading these enthusiastic users to think that a completion style such as orderless, or any other Elisp style, can be used with LSP at all is just misleading and detrimental to the work here. I regret that I have to clarify this again and again.

I'm not undermining Corfu or the energy of other programmers. Opinions are fine and boy are there a lot of them. I'm just resisting @jdtsmith's opinion that Eglot should change the way it works to adapt to a newfound interpretation of what a longstanding API actually means. Noone seems to be able to argue for actual tangible benefits of another interpretation of the API, and that's likely because there aren't any.

I agree that ideally the packages should just work together out of the box. But I'd like to note that Corfu has a github wiki that has a section Configuring Corfu for Eglot, which talks about the completion-styles override in Eglot (not sure that's still up-to-date). Temporarily, while the issue is not resolved, I adapted and added the cape-capf-buster advice by @jdtsmith #1127 (reply in thread) to that wiki.

Suggesting monkey-patches to Eglot to solve problems in third-party packages is just... regrettable. This just makes tracking down actual bugs more difficult. This is why I insist so much on emacs -Q recipes.

As to this "sync" bug, I mentioned earlier that Corfu messes with undo change groups, but I couldn't be sure if that was the culprit. Well it seems it doesn't mess with these things anymore: minad/corfu#309 and minad/corfu@eeaec80. Who knows if this also fixes the issue here?

[meliache]

I agree with everything said 👍

The Corfu Wiki is not maintained by the dev and I already noted it might be out-of-date, but as I understand you that suggestion might never have been up-to-date but just wrong. That's the problem with Wikis. Sorry for having to repeat yourself.

but its company-capf backend is perfectly well suited for Emacs's completion infrastructure. I once suggested that all the other backends be deprecated. Which would be reasonable. But it's also reasonable to keep them, because they usually don't really hurt anything just by being there, and when they do it's pretty easy to remove them.

I agree company-capf works great and the existing other backends don't hurt. Imo an issue is that new Emacs packages are still being written that only come with a company-backend and not a CAPF, because the author was aware of the former but not the latter. There the deprecation of other backends might have helped, though I wouldn't argue in favor of that. I think the existence of Corfu and Cape has at least been good PR for CAPF's. At least this is what caused me to reach out to the company-org-block and mastodon.el authors asking to (or helping with) implement a CAPF-completion, which was quickly implemented in both cases. But I agree that I could have also done that without Corfu and just use company-capf-only 🤷‍♂️

[jdtsmith]

Fortunately, company does not look solely at its own belly button and understands that are other ways to complete things in the buffer, which don't involve the concept of a "session" or a dropdown. The backend shouldn't make assumptions about the form the UI takes.

I just used company and corfu as examples. There is the in-built completion-in-region, which as mentioned stores the collection table while the mode is active (see completion--in-region). Plenty of "vanilla extract" (love that!) purists are reaching for it now. I don't know if the same issue with eglot exists with vanilla completion-in-region, but I do believe it does not "dump and re-call" the CAPF while the mode is active.

Leading these enthusiastic users to think that a completion style such as orderless, or any other Elisp style, can be used with LSP at all is just misleading and detrimental to the work here.

I am responsible for this part of the wiki. I've just added a disclaimer repeating the point that completion styles cannot and do not impact the candidates your LSP server provides; feel free to edit it if you don't think it's clear. That said, I use orderless with eglot together daily, and enjoy the combination. No, the LSP server does not understand orderless. But neither does dabbrev, for example. In fact, in my experience, basically only the elisp capf has the super-power of providing "all possible completions of any sort whatsoever" that enables completion styles to work perfectly (nice when you have all symbols in addressable memory!). That said eglot+orderless still remains a very useful combination to me for down-selecting from a large list of candidates. If users are misunderstanding the capabilities of completion styles when applied to externally generated completions, I think better documenting those limitations is the right approach.

Suggesting monkey-patches to Eglot to solve problems in third-party packages is just... regrettable.

This is not in the least what I am suggesting. Slinging mud like this doesn't typically improve an argument. (edit: I suspect you are just referring here to the need for cape-capf-buster; apologies if I misinterpreted). I understand you have very firm and perfectly reasonable opinions on the details of how completion should go, possibly informed by years of using company. Others have firm opinions which conflict with yours, based on their own distinct experiences. And that's fine. It's a diverse ecosystem. Tools come and go. The key is to find ways to productively bridge differences.

[jdtsmith]

Good thoughts. I think for "full capf busting" you need valid=never? It would be useful if a default configuration of corfu+eglot worked out of the box; many users don't discover the wrapper or particularly need cape.

This discussion is actually about a more pernicious if rare issue of the LSP server getting out of sync with the buffer contents, exclusively when corfu is used. It seems input-interruption is not the culprit (@joaotavora disabled it and it recurred). with-silent-modifications and undo-groups have been suggested as possibilities. If you had thoughts on these, or how to investigate, that would be appreciated.

[minad]

This discussion is actually about a more pernicious if rare issue of the LSP server getting out of sync with the buffer contents, exclusively when corfu is used.

I got pinged about this issue before and then suggested that interrupts could be a possible cause of this. Fortunately this seems not to be the case.

with-silent-modifications and undo-groups

with-silent-modifications is not used by Corfu in the original buffer. It is only used when formatting the buffer backing the popup. I am not sure about undo change groups - how could they cause issues? Corfu starts a change group at the beginning of completion, and in the end of completion amalgamates and accepts the group, such that the completed string can be easily reverted at once. It is easy to check if this causes issues - just remove all the change-group-related code and try out this patched version of Corfu.

[joaotavora]

how could they cause issues?

No idea. They are just suspicions, as I pointed out. For all we know the problem might be in Emacs itself, or Eglot, of course. I tested with Emacs -q so it must be one of these. I didn't dig deep into corfu's code. It was just my last resort. But the report of minad/corfu#309 is somewhat familiar in that it suggests that corfu's undo behaviour is not deterministic and depends on timing parameters. And undo behavior is also based on before and after change functions, so there's a fairly strong connection to this issue. Might be (another) red herring, of course, just like the interruption suspicion.

[joaotavora]

I am responsible for this part of the wiki. I've just added a disclaimer repeating the point that completion styles cannot and do not impact the candidates your LSP server provides; feel free to edit it if you don't think it's clear.

@jdtsmith when I work on Eglot, which is a project I started, I have a certain budget of hours to spend in its development, promotion, documentation and user support. This is my time, which is very dear to me, and I, like you, and so many in this OSS world, give it away absolutely for free. We do it for fun, not profit. I don't think I should be expected to discover which wikis or forums are providing bad advice and go and edit them.

When people use M-x eglot and run into a bug anywhere in their contorted Emacs setup, it's a high likelyhood they will report it to Eglot. This is perfectly reasonable, because Eglot is today, in many respects a frontend to much of the funcionality of Emacs right now. So any wikis or forums that generate false expectations about Eglot's true capability increases the likelihood of one of these bug reports. And that bites into my time.

So, if you please, add something to that wiki saying that any typical Emacs completion style will, in general, not work with Eglot and Eglot's author doesn't recommend it. I'm sure you understand the problem as well as I do by now, so you're perfectly qualified to add that, you're probably a much better English speaker/writer than I am.

That said, if orderless works for you, so much the better I'm so happy for you. I wish I could support it properly, as well as a lot of other styles. But as you know, it can't work well in the general case unless the LSP server somehow dumps all its possible completions every time to Emacs. As you suggest there, you can increase the number of completions, but then you get performance problems (again more bug reports and the reddit illuminati bravely stating that "threads" or "rust emacs" or "thingamabob2000" would solve it). But if you get all the completions to get your nice elisp styles to work, you're basically going against LSP logic, which is to offload to the server a bunch of stuff we're used to seeing in our dear editors. Transmitting huge amounts of data over JSONRPC is just not good.

LSP is a nice thing to have, but it might not be "the future". Look into integrating language servers libraries in the Emacss process memory address space if you truly want to solve this problem. Moving memory around is much, much faster.

Or maybe, less ambitious, look into making a lazy JSON library using generators, maybe that has some effect, but in the end it's also a bit handicapped.

Also I did not mean to "sling mud". I didn't know you had authored the wiki. I just referred to monkey patching because Elisp advice of another package's function, which is ipsis verbis what the wiki suggests, is monkey patching. I also do it, in my config, here and there. But I take if out immediately when reporting a bug.

[meliache]

I should take some blame, the monkey patching, i.e. the elisp-advice of eglot-completion-at-point with cape-capfs-buster in the Wiki was written by me today. I (over-?) eagerly adapted some suggestion given by @jdtsmith in this discussion thread and thought it might be helpful to document that. As far as I understood, that advice makes Corfu behave more in line with Eglot's expectation, i.e. re-calling the outer CAPF on every change to the string being typed. But even though the advice aims at changing Corfu's behavior, it's an advice to an Eglot function and I see the issue with that. I see your points and it might be more helpful to properly fix something or report an issue rather than providing monkey-patches.

The completion-styles override is separate and that existed in that Wiki page for a while. I noticed that @jdtsmith just improved the phrasing following the discussion today, adding some more nuance in that this doesn't affect Eglot, just the filtering of candidates provided by the language server. (Also @minad, sorry for overly eagerly deleting that paragraph entirely). I see a warning has been added to the section on configuring the language server to provide more completion candidates due to performance concerns. Maybe I'll add explicitly that you recommend against it.

But if you get all the completions to get your nice elisp styles to work, you're basically going against LSP logic, which is to offload to the server a bunch of stuff we're used to seeing in our dear editors. Transmitting huge amounts of data over JSONRPC is just not good.

This made me wonder (thinking aloud here): I believed LSP was invented to solve the progamming-language-editor matrix, by having a language server provide all language-specific features, which requires understanding of the programming language. Generating possible completion candidates might be one of those features, but filtering already generated completion candidates using something like orderless seems in theory language-agnostic (or isn't it?), so it doesn't seem to have a "language-matrix" problem. But, beyond that, I have no idea what the LSP designers had in mind and I know that Joao is much more knowledgeable on that. I agree that in practice, most language server designers didn't consider Emacs completion styles and most language servers are not designed with Emacs post-filtering of completions in mind. And your point with transmitting huge amounts of data over JSONRPC is definetly valid. For the normal user, I think it matters most that Eglot completion just works and is responsive and there I'd recommend what's least complex and just work with the capabilities and intended usage of the language server, even if it's a pity that completion-styles are not respected. And I agree to put big fat warnings on hacky workarounds, as I understand your dismay with the load they put on you as a maintainer. Tbh, if a language server has a public setting to increase the limit to the number of candidates, that's no even really a hack or unintended behavior, but I wouldn't recommend going much beyond the defaults considering the performance-implications that has.

[joaotavora]

(over-?) eagerly adapted some suggestion given by @jdtsmith in this discussion thread and thought it might be helpful to document that. As far as I understood, that advice makes Corfu behave more in line with Eglot's expectation, i.e. re-calling the outer CAPF on every change to the string being typed.

In the meantime I have educated myself about this cape idea, and while it is indeed monkey patching, and inherently dangerous, it is not the most dangerous of its kind, since Eglot's capf follows a strict protocol, and if that cache-buster thing is well designed, it will work, I guess. But the general principle is still a bit shady. I still thing corfu should be cache-busting (or "defensive", as someone wrote here) by default, but hey if the cape is rock solid and never ever spells trouble, who am I to judge what people do in their .emacs?

I hope that:

1. Daniel's fix to Corfu will fix the sync issue 🤞 . If it doesn't, I'll keep trying to debug it as time permits
2. the wiki will be updated to state that this cache-busting is "use-at-your-own-peril"
3. the clarification about the intrinsic limitation of Eglot regarding Emacs completion styles such as orderless, flex, regexp, etc is well underlined in that wiki

[minad]

1. Daniel's fix to Corfu will fix the sync issue

I hope so. The undo-boundary call was definitely problematic. If this doesn't fix it I could even remove the entire undo change group code, but then I doubt that this would help. The functions activate-change-group and undo-amalgamate-change-group seem unproblematic. As I see it, there is no messing around with after-change-functions or anything else except the undo list. How could they lead to desychronization here?

2. the wiki will be updated to state that this cache-busting is "use-at-your-own-peril"

Cache busting is quite harmless actually. It recalls the Capf if the input changed and then updates the internal table. Just look at the code:

(defun cape-wrap-buster (capf &optional valid)
    (pcase (funcall capf)
      (`(,beg ,end ,table . ,plist)
       `(,beg ,end
              ,(let* ((beg (copy-marker beg))
                      (end (copy-marker end t))
                      (input (buffer-substring-no-properties beg end)))
                 (lambda (str pred action)
                   (let ((new-input (buffer-substring-no-properties beg end)))
                     (unless (cape--input-valid-p input new-input valid)
                       (pcase (funcall capf)
                         (`(,_beg ,_end ,new-table . ,_plist)
                          (setq table new-table input new-input)))))
                   (complete-with-action action table str pred)))
              ,@plist))))

One can even use this without an advice and then use this new function uncached-eglot-capf instead of eglot-completion-at-point-function. Just function composition, nothing shady is going on here.

(defalias 'uncached-eglot-capf (cape-wrap-buster #'eglot-completion-at-point))

3. the clarification about the intrinsic limitation of Eglot regarding Emacs completion styles such as orderless, flex, regexp, etc is well underlined in that wiki

I agree with that. The wiki already outlines these limitations but it could and should do better.

[joaotavora]

How could they lead to desychronization here?

I told you, I don't know, wish I did. But the undeterministic undo behaviour related to timing parameters in elisp-mode that someone recently reported is also inexplicable (at least to me) and nevertheless your change seems to have improved it. undo is related in C code to the code that prepares and records buffer changes. If undo was failing so could well the recording of before/after changes. And Eglot's sync relies on those. Just a conjecture.

just function composition, nothing shady is going on here.

It's just another monkey-patching technique in my book: altering the implementation of a library you can't change directly to gain a functional change elsewhere, in this case being able to call the outer function by calling the internal one. I get it, very clever. I don't get why you want to do this pirouette instead of simply (at least by default) calling the outer one in your UI, but let's not argue that.

I agree with that. The wiki already outlines these limitations but it could and should do better.

Thanks and if you can, also remove the suggestion that Company's backends are incompatible with Emacs infrastructure, As a capf proponent and specialist, at least mention company-capf which has existed for a loong time.

[AkibAzmain]

I tried with Company, but the server still got out of sync. (So much that Flymake started signaling errors.) Server: Clangd.

[EDIT by @joaotavora: In the interest of future readers of this issue (my traffic analytics indicate there are more than a few),
I'd like to underline that the above comment and statement is completely bereft of any evidence.

In other words, and to be blunt, I have to call it bullshit.

See this comment #1127 (comment) for a reproducible experiment with both Corfu and Company which Corfu consistently fails and Company consistently passes. ]

[joaotavora]

If that were true, and Company were the culprit, I should have seen it by now. I use Clangd+Eglot+Company every day intensely in small and large projects alike, keeping Eglot sessions and buffers open for days if not weeks long. Never see a desynch.

It could be something else in your configuration, which you haven't reported.

[joaotavora]

Just for completeness sake and in case I hadn't described that before, when I tried Corfu, I was able to see a desynch within 5-10 minutes of use. The problem of course is that it was too unpredictable to allow any proper investigation into the root cause.

[joaotavora]

I've again tried this bug, after reading some discussion elsewhere. As far as i can tell, the problem hasn't gone away. Here's a slightly easier repro from scratch, using just a GUI Emacs 30 and the clangd server:

HOME=`mktemp -d` /path/to/emacs --eval '(package-install (quote corfu))' /tmp/thingy.cpp   \
-f eglot \
-eval '(setq corfu-auto t corfu-auto-delay 0.1)' -f global-corfu-mode

This installs corfu from scratch in a pristine sandbox, configures it minimally to behave like Company and starts Eglot automatically.

/tmp/thingy.cpp 's contents is just:

#include <iostream

int main() {
  std::

Now after starting up, type printf and after the popup appears delete it one by one with backspace. Maybe delete back to the std::. Do this some 5-10 times and you eventually and consistently get to the desynch.

When I try the same experiment with Company, I NEVER get out of synch or any problems.

Here's the Company one liner:

HOME=`mktemp -d` /path/to/emacs --eval '(package-install (quote company))' /tmp/thingy.cpp -f eglot -f global-company-mode

It's of course essentially impossible to prove a negative, like proving that Eglot doesn't cause cancer or the Hinderburg disaster, but the evidence is nevertheless overwhelming

[joaotavora]

RE the cause, maybe this is a better analog?

Yes, I think that could be it. When the while-no-input is there, the unless finished doesn't run. I tested with this slightly
different form.

(message "GOT WNI %S"
         (let ((finished nil))
           (while-no-input
             (unwind-protect
                 (setq finished
                       (catch 'tag
                         (run-at-time 5 nil
                                      (lambda ()
                                        (unless (eq finished 'cancelled)
                                          (throw 'tag 'success))))
                         (progn (sit-for 30) 'cancelled)))
               (message "leaving early with finished=%s" finished)))
           finished))

That's quite interesting. This caching is provided by eglot-completion-at-point, outside the completion table itself?

Yes.

[jdtsmith]

Any further developments here? Has the jsonrpc throw-on-input=nil patch been working for people? Would be good to get that released if so and update the various threads/wikis.

[joaotavora]

Thanks for pinging. I've now pushed this fix to lisp/jsonrpc.el in Emacs master:

commit 5a0250f76676d8750f42bbca1af5c4553846949b (HEAD -> master)
Author: João Távora <[email protected]>
Date:   Tue Nov 28 18:47:09 2023 -0600

    Jsonrpc: prevent while-no-input messing with jsonrpc-request

    'jsonrpc-request' already has its "interrupt on user input" mechanism
    base on 'sit-for'.  If called from a situation that uses
    while-no-input to do basically the same, that mechanism may become
    confused, so it's important to prevent that interfence.

    This was confirmed to be a problem when using the Corfu completion
    front-end.

    See also
    https://github.com/joaotavora/eglot/discussions/1127#discussioncomment-7277567

    Many thanks to JD Smith <[email protected]> for helping me debug this
    and pointing in the right direction.

    * lisp/jsonrpc.el (Version): Bump to 1.0.18
    (jsonrpc-request): Bind throw-on-input to nil

It should find its way into GNU ELPA soon, so any new installation of Eglot should pick up on it automatically (since package.el always seems to pick the newest version of a dependency).

So hopefully this is fixed.

[jdtsmith]

This seems to be fixed for me with the while-no-input protection in jsonrpc. At least the sync issue has never recurred. Barring evidence to the contrary, can I suggest you update the EDIT of the top post?

[joaotavora]

Makes sense, will do.