evil-collection
evil-collection copied to clipboard
`company-active-map` overridden when using company doc-buffer
When using company completion, if you open the doc buffer (C-h
) thencompany-active-map
will loose priority to evil-insert-state-map
. This means that keys like C-n
, C-p
, and C-k
no longer work for navigating the popup (interestingly C-j
still seems to work in this broken mode).
I was able to trace back this issue to this line in company-doc-buffer
https://github.com/company-mode/company-mode/blob/16ffeba5ef96c4c8e0cd39860b5402e25e304601/company.el#L2831
to reproduce:
- Begin company completion
-
C-h
to open the doc buffer -
C-n
will no longer work and will instead callevil-complete-next
(The insert state binding)
https://github.com/company-mode/company-mode/blob/16ffeba5ef96c4c8e0cd39860b5402e25e304601/company.el#L2831
What's wrong with this line?
I can reproduce only when the first company candidates menu pops up. Later, it works well.
Thanks for taking the time to reproduce the issue.
What's wrong with this line?
That is as far as I was able to trace the issue. If you remove that logic, the issue goes away (but doc buffer obviously won't work). I don't know why it has that impact on the evil keymap.
I can reproduce only when the first company candidates menu pops up. Later, it works well.
I am not sure what you mean by "later, it works well". It doesn't permanently break the keymap, but for the remainder of the time company is active it is now overridden by evil-insert-state-map
. Effectively meaning you can no longer select candidates. If you start a new company completion, then the keymaps will have their correct priorities (until you try and open the doc buffer again). So it sounds like we are saying the same thing.
I decided to go see what doom does and indeed they have a hack to fix this as part of doomemacs/doomemacs#1335. See the fix below.
https://github.com/doomemacs/doomemacs/commit/2e476de44693c9f4953f3c467284e88b28b6084e
I tested their fix and it works. Is this something we should add to evil-integration? If so I can put together a PR.
(add-hook! 'evil-local-mode-hook
(when (memq 'company-emulation-alist emulation-mode-map-alists)
(company-ensure-emulation-alist))))
@dgutov What do you think? Is it a company-mode bug?
Is it a company-mode bug?
I don't know, you tell me.
Without Evil, with normal Emacs bindings, C-n
and C-p
continue working after C-h
.
Maybe something in the current keymap jugging could be improved to make the Evil users' life easier. But someone will need to tell me what that is.
@CeleritasCelery Could it happen with company-20220731.2333
? I'm trying to reproduce, but failed.
Maybe something in the current keymap jugging could be improved to make the Evil users' life easier. But someone will need to tell me what that is.
Thanks.
I just grabbed the latest version of the packages from git:
- company-mode
f1877a3
(would be something like 20220801) - evil
3045e42
- evil-collection
c005e07
And I am still able to reproduce the issue.
looking at the code more, I see this code in evil in setting the emulation mode:
(setq emulation-mode-map-alists
(evil-concat-lists '(evil-mode-map-alist)
emulation-mode-map-alists))
What I think is happening is that when we call company-doc-buffer
it is creating a new buffer to display the docs and that is calling evil-local-mode
again, which is overriding company-mode as the start of the emulation alist.
The two ways I can see to fix this would be to have company call company-ensure-emulation-alist
at the end of company--show-doc-buffer
(I tested this and it works).
However I don't think this would fix all the issues. For example I suspect that https://github.com/doomemacs/doomemacs/issues/1335 would still not be fixed.
It seems odd to fix this in company-mode, since the issue only appears when using evil. That is the idea behind evil-collection
is to fix these cross package compatibility issues.