tumashu / vertico-posframe

GNU General Public License v3.0
119 stars 16 forks source link

Doesn't properly respond to C-n #11

Open agzam opened 2 years ago

agzam commented 2 years ago

I'm dealing with this curious, though an awfully annoying problem, and I can't figure out what's causing it. This thing happens only when I have vertico-posframe-mode enabled. It doesn't happen all the time - only once in a while but affects every kind of completion. I do something, it would create the posframe buffer, but whenever I press C-n, instead of navigating to the next item in the list, it paints the border of the frame to a different color. And as I keep pressing C-n, it keeps changing the colors. Interestingly, C-g or Esc doesn't immediately cancel this behavior. It goes back to the previous color. As if every time, it creates a new posframe buffer on top of another, but with different border color.

vertico-posframe-bug

To reproduce:

tumashu commented 2 years ago

I think minibuffer-depth changed when press C-n

(defun vertico-posframe--get-border-color ()
  "Get color of vertico-posframe border."
  (face-attribute
   (let* ((n (minibuffer-depth))
          (face (intern (format "vertico-posframe-border-%s" n)))
          (face-fallback 'vertico-posframe-border-fallback))
     (if (= n 1)
         'vertico-posframe-border
       (if (facep face)
           face
         face-fallback)))
   :background))
agzam commented 2 years ago

I'm sorry, not sure what you're trying to tell me. I don't understand what this function has to do with the behavior I describe. I tried tweaking it and only found a way to keep the border's color unchanged. C-n is still unusable, at least until you kill the posframe and start it again. Were you able to reproduce the bug?

tumashu commented 2 years ago

I can not reproduce for I do not use evil, I mean when you type C-n, you seem to enter recursive minibuffer, so (minibuffer-depth) will change, result different color border, but why C-n will enter recursive minibuffer? I do not know.

agzam commented 2 years ago

Damn thing finally annoyed me to the point that I had to sit down and deal with it. After digging through things, I did this:

   ;; `defadvice`! is Doom's syntactic sugar for advising, pretty similar to `(advice-add)`
  (defadvice! vertico-posframe--display-no-evil (fn _lines)
    :around #'vertico-posframe--display
    (evil-mode -1)
    (funcall-interactively fn _lines))

  (add-hook! 'minibuffer-exit-hook #'evil-mode)

It looks stupid, but I think it works. This is a workaround for anyone who's just like me - annoyed by C-n not working.

jidibinlin commented 2 years ago

I have the similar problem. C-n won`t work when emacs started. But will work fine when i reuse it. This problem seems only for evil.

jidibinlin commented 2 years ago

@agzam Hi! If you use evil-collection with evil. I think you can solve this problem in this way

  (use-package evil-collection
    :after evil
    :demand t
    :ensure t
    :custom
    (evil-collection-want-unimpaired-p nil)
    (evil-collection-setup-minibuffer t)
    :config
    (evil-collection-init)
    ;;(global-evil-collection-unimpaired-mode -1)
    )

make sure evil-collection-setup-minibuffer bind to t