Accepting company completion causes LSP document to get desynced

[robbert-vdh]

This has been an issue for as long as I can remember, but I always forget to create a ticket for it. Not sure if this is the same issue as #39, but it also happens in Doom with the pinned iedit version.

When accepting a company completion while multiple evil-multiedit regions are active, the prefix that was used to trigger the company completion doesn't seem to get committed to the other regions while the completed part does. See below for a demonstration where lsp-mode's capf backend completes bar for me after I typed a b. When the document automatically reformats on save through lsp-format-buffer, only the ar part remains.

simplescreenrecorder-2021-06-13_13.48.21.mp4

On a side note, is pasting on a visual selection being broken in evil-multiedit (with Doom) also a known issue? When I use viw p to replace the selected word, only the actual word I'm editing will contain the pasted text. The other regions will be empty.

[hlissner]

On a side note, is pasting on a visual selection being broken in evil-multiedit (with Doom) also a known issue? When I use viw p to replace the selected word, only the actual word I'm editing will contain the pasted text. The other regions will be empty.

This was fixed in a451370 (and reported in #39).

When accepting a company completion while multiple evil-multiedit regions are active, the prefix that was used to trigger the company completion doesn't seem to get committed to the other regions while the completed part does. See below for a demonstration where lsp-mode's capf backend completes bar for me after I typed a b. When the document automatically reformats on save through lsp-format-buffer, only the ar part remains.

This is tricky. I believe this is because lsp-format-buffer rewrites the entire buffer, so overlay positions are effectively wiped. I can't think of an acceptable way to preserve those overlays through such a potentially destructive process.

I could have evil-multiedit abort the session when the file is saved -- it's not optimal UX, but it'd at least avoid this weirdness. Give it a try:

(with-eval-after-load 'evil-multiedit
  (add-hook 'before-save-hook #'evil-multiedit-abort))

[robbert-vdh]

Accepting a completion with lsp-mode doesn't seem to save the buffer for me (I do have lsp-enable-on-type-formatting enabled, but that doesn't seem to make any difference). This is what happens for me after adding that hook:

simplescreenrecorder-2021-10-23_20.59.34.mp4

[hlissner]

Is evil-multiedit up-to-date? I see you're using Doom, where I've pinned both iedit (and evil-multiedit) to older commits. I've made quite a few changes in the past few hours (and others have claimed that changes upstream to iedit have solved its interop with some packages, like tree-sitter (#40)), so try unpinning them (and lsp-mode, for good measure):

;; add to ~/.doom.d/packages.el
(unpin! iedit evil-multiedit lsp-mode)

Then run doom sync -u and restart Emacs.

[robbert-vdh]

Oops yeah I was going to mention that but I forgot about it, sorry, I hadn't updated in a couple of days (and I assumed no sneaky buffer saving had snuck in in the mean time). I unpinned those packages, updated to the latest develop branch, and cleaned my ~/.emacs.d/.local/straight for good measure, but now evil-multiedit-match-symbol-and-next complains evil-digit-bound-motions hasn't been defined and I'm not quite sure which library is supposed to provide that.

[hlissner]

Oh, my bad, I forgot about evil (which very recently introduced evil-digit-bound-motions)! That needs to be unpinned too:

 ;; add to ~/.doom.d/packages.el
-(unpin! iedit evil-multiedit lsp-mode)
+(unpin! iedit evil-multiedit lsp-mode evil)

[robbert-vdh]

Ah yeah I thought about that, but I was thinking "Surely evil-multiedit doesn't require some bleeding edge new evil feature, right?". 😅

With these changes (and without having to add the 'before-save-hook) accepting these company candidates seems to actually mostly work for me! The iedit keymap seems to override some keys it's not supposed to (like M-D), but you were probably already aware of that. And the yasnippet expansion is a bit wonky, but that's probably to be expected. Accepting a completion does seem to trip up undo-fu though. The main region that's being edited seems to have one additional undo step compared to the other occurrences, but I don't think that's causing any other weird inconsistencies.