Missing content and focus lost

[thomasheartman]

Hey again 👋🏼

Thanks a lot for the package! 90% of the time it is absolutely great! But I do have a two issues that pop up semiregularly. I'll add them both in this issue for now (but I would be happy to split them out if you prefer).

Update: I realized I was not on the latest version of this package (about a year behind). That's been rectified now. I couldn't reproduce the focus issue, at least. I don't know about the missing text, because that appears to happen just whenever. I'll leave the issue open for now in case the first issue is new or the second one reappears, but it is possible that both of these are fixed.

1: Missing text

Description

Sometimes, the frame doesn't seem to render all the text correctly. In the following screenshot, I've started typing confi, but what shows up seems to be missing most characters:

Expected outcome

I'd expect it to render correctly. For reference, this is what I get when it renders as I expect.

Steps to reproduce

Sadly, I don't know how to reproduce this. It seems to happen at random.

2: Focus lost (Edit: may not be an issue)

Description

Sometimes, when performing interactive commands, such as consult-ripgrep, the focus shifts to the main buffer as I'm typing the search string, causing the mini frame to lose focus and the background buffer to gain focus and receive unwanted input.

This also causes the mini frame to remain open while focus is in the other buffer, and I haven't found a reliable way to move focus back to the mini frame without using the mouse. To close it, doing M-x to try and force open a different menu seems to work.

This seems similar to #37, but is not solved.

Image of when it happens:

Expected outcome

I'd expect the focus to remain in the minibuffer until I select one of the options.

Steps to reproduce

This isn't 100%, but this seems to be the case:

1. Trigger consult-ripgrep (it might work with other commands, but I don't know)
2. As soon as you can start typing a string you're searching for. The longer it is (or the larger the repo is?), the more likely it is to trigger, it seems.
3. Watch the point move to the buffer and the mini frame be left alone.

Thoughts

This may related to consult, which shows you a preview of the whole buffer as candidates are selected. That means that the buffer you're seeing behind the mini-frame can change rapidly while you're typing. I've consulted their issues and I know there are issues with how mini-frame and consult work together. However, I thought I'd mention it anyway, in case it helps us find a solution in some way.

mini-frame configuration

For reference, here's the configuration block I'm using:

(use-package mini-frame
  :unless (string= "t" (getenv "SUPPRESS_MINI_FRAME"))
  :custom
  (mini-frame-show-parameters '((top . 15)
                                (width . 0.5)
                                (left . 0.5)
                                (alpha . 80)))
  (mini-frame-resize 'resize)
  (mini-frame-color-shift-step 0)

  (custom-set-faces
   ;; set a border for the child frame mini frame uses. Set it to the
   ;; default text color.
   `(child-frame-border ((t (:background ,(face-attribute 'default :foreground))))))

  :config
  (setq mini-frame-standalone nil)
  :init
  (mini-frame-mode))

---

Thanks for listening and thanks again for the package! Any input is much appreciated 😄

[thomasheartman]

Hi! Just wanted to chime in to say that I've been using the most recent version of this package (60838f3) for the past few days now, and I can confirm that both of these issues are still relevant. I have been seeing less of the focus issue, but it's not entirely gone.

[jaaasonSun]

Hi, just want to add that I'm seeing the focus lost issue as well. I'm able to reproduce the issue with lsp-mode.

[11111000000]

use exwm and vertico:

projectile-switch-project show me:

but, when I do the same, when on frame with firefox opened, it works ok!