Conflict with consult?

[BooAA]

I have encountered some issues when using the preview feature of consult with mini-frame. See minad/consult#286 for details.

[muffinmad]

Can you please test it on other Emacs version? I can't see attached video in the linked issue. What I've tried:

1. emacs -Q
2. M-x mini-frame-mode
3. M-x selectrum-mode
4. M-x consult-buffer

Seems like it works as expected: preview of the selected buffer is shown and the previous buffer is restored on C-g.

I'm using Emacs 28 NS-port (not native-comp).

[BooAA]

I can't see attached video in the linked issue.

I use chrome in desktop, video playing normally, are you using mobile device? (Firefox also report video not played and file is corrupted, not sure why)

I find this bug not 100% reproducible, somehow if I start Emacs with -Q and eval configs line by line, the bug seems to disappear.

Below is what I use as a minimal config to test:
OS: Debian/sid
Emacs 28 master (without native-compilation)

;; init.el
(package-initialize)
(require 'selectrum)
(require 'mini-frame)
(require 'consult)
(selectrum-mode)
(mini-frame-mode)
(global-set-key [remap switch-to-buffer-other-window] #'consult-buffer-other-window)

After starting emacs with config above, use C-x 4 b to invoke consult-buffer-other-window and type several characters, then the contents of whole minibuffer disappear, remain just the background color. This is not 100% reproducible, you may have to try many times. Also, only consult-buffer-other-* series commands seems to have this problem, if I memory is correct I've never encountered any issue with consult-buffer.

Screenshot (result after typing "*s" to search for *scratch* buffer)

I doubt about whether this is really bug related with mini-frame or is some weird display engine bug related with internal Emacs, hope above information helps.

[muffinmad]

I use chrome in desktop, video playing normally, are you using mobile device? (Firefox also report video not played and file is corrupted, not sure why)

The video is not shown under Safari. Works fine under Chrome though.

I find this bug not 100% reproducible

Oh, my favorite ones :)

Below is what I use as a minimal config to test:
OS: Debian/sid
Emacs 28 master (without native-compilation)

;; init.el
(package-initialize)
(require 'selectrum)
(require 'mini-frame)
(require 'consult)
(selectrum-mode)
(mini-frame-mode)
(global-set-key [remap switch-to-buffer-other-window] #'consult-buffer-other-window)

Checked this receipt in Emacs 28 under Gnome Shell. Except added one additional line:

(setq x-gtk-resize-child-frames 'resize-mode)

Can't reproduce the issue so far.

I doubt about whether this is really bug related with mini-frame or is some weird display engine bug related with internal Emacs, hope above information helps.

Unfortunately I have no idea what's going on at the moment.