bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

To reproduce the issue, please start Emacs with:

    $ emacs -Q

Then put the following form in the *scratch* buffer and evaluate it with
C-x e:

    (let ((f (selected-frame)))
      (with-selected-frame (make-frame)
        (switch-to-buffer (get-buffer-create "other")))
      (select-frame-set-input-focus f)
      (let ((win (get-buffer-window "other" t)))
        (when win
          (with-selected-window win
            (recenter 0)))
        (with-selected-window (minibuffer-window)
          (unwind-protect
              (progn
                (setq-local face-remapping-alist `((default :height 2.0)))
                (insert "hello")
                (read-key))
            (erase-buffer)))))

"hello" is shown in the minibuffer, but it is partially hidden.

For comparison, in Emacs 28.1, "hello" is fully visible.

Can you reproduce this issue, and if possible, could you please restore
the behaviour of Emacs 28.1 and earlier versions for this example?

Thank you and all the best,
Markus

In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2023-12-08 built on mt-book
Windowing system distributor 'The X.Org Foundation', version 11.0.12201003
System Description: Ubuntu 23.10

Configured using:
 'configure --with-x-toolkit=lucid --with-gif=no --with-tiff=no
 --with-gnutls=no'

Configured features:
FREETYPE GMP JPEG LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP
SOUND THREADS TOOLKIT_SCROLL_BARS X11 XDBE XFT XIM XPM LUCID ZLIB

Important settings:
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: de_DE.UTF-8
  value of $LC_TIME: de_DE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

tags 67715 wontfix
thanks

> From: Markus Triska <triska@metalevel.at>
> Date: Fri, 08 Dec 2023 20:03:32 +0100
> 
> To reproduce the issue, please start Emacs with:
> 
>     $ emacs -Q
> 
> Then put the following form in the *scratch* buffer and evaluate it with
> C-x e:
> 
>     (let ((f (selected-frame)))
>       (with-selected-frame (make-frame)
>         (switch-to-buffer (get-buffer-create "other")))
>       (select-frame-set-input-focus f)
>       (let ((win (get-buffer-window "other" t)))
>         (when win
>           (with-selected-window win
>             (recenter 0)))
>         (with-selected-window (minibuffer-window)
>           (unwind-protect
>               (progn
>                 (setq-local face-remapping-alist `((default :height 2.0)))
>                 (insert "hello")
>                 (read-key))
>             (erase-buffer)))))
> 
> "hello" is shown in the minibuffer, but it is partially hidden.
> 
> For comparison, in Emacs 28.1, "hello" is fully visible.
> 
> Can you reproduce this issue, and if possible, could you please restore
> the behaviour of Emacs 28.1 and earlier versions for this example?

The change which caused this cannot be reverted, since it will
reintroduce a worse bug (bug#24285).

Why did you expect the mini-window to resize in this case?  Emacs
doesn't resize a window just because you enlarge a font shown in that
window, which makes some of the text invisible because it not longer
fits into the window's dimensions.  The automatic resizing of the
mini-window is reserved for its uses to prompt the user and to show
echo-area messages, whereas your snippet just uses it as a normal
window showing some buffer.

So I don't think we will change this behavior, and you will need to
find another way of ensuring the enlarged text is visible, in your
real-life use case.

Sorry.

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> Why did you expect the mini-window to resize in this case?

The Emacs Lisp documentation states in section 21.1:

    The minibuffer’s window is normally a single line; it grows
    automatically if the contents require more space.

I therefore expected it to grow automatically in the case I posted,
especially also because this is done in many Emacs versions before 28.2,
such as 26.1, 26.2, 26.3, 27.1, 27.2 and 28.1.

> find another way of ensuring the enlarged text is visible, in your
>
I added (fit-window-to-buffer) after inserting the text, and still the
text is not fully visible. fit-window-to-buffer is documented as:

    Adjust size of WINDOW to display its buffer’s contents exactly.

I would greatly prefer if Emacs works as documented. Should I file a
separate issue for this, or is this also a case of wontfix? Is there any
way to solve the issue?

Thank you a lot!
Markus

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 67715@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 08:04:40 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why did you expect the mini-window to resize in this case?
> 
> The Emacs Lisp documentation states in section 21.1:
> 
>     The minibuffer’s window is normally a single line; it grows
>     automatically if the contents require more space.

As I said, this is currently limited to showing echo-area messages and
prompts for the user to type some input.  The text above didn't
imagine someone will want to use the mini-window as a normal window
and just insert there some arbitrary text.

> I added (fit-window-to-buffer) after inserting the text, and still the
> text is not fully visible. fit-window-to-buffer is documented as:
> 
>     Adjust size of WINDOW to display its buffer’s contents exactly.
> 
> I would greatly prefer if Emacs works as documented. Should I file a
> separate issue for this, or is this also a case of wontfix? Is there any
> way to solve the issue?

I don't know.  You haven't actually explained what you are trying to
accomplish and why you use this strange way of accomplishing it.  Why
not, for example, use the minibuffer-prompt face instead to show the
prompt in a different typeface?

But yes, it is possible that we will not want to fix that, since the
change was to solve a more serious issue, and I don't see how these
two issues could be reconciled given the way redisplay currently
works.

The basic technical reason for what you see is that redisplay is
inhibited when with-selected-window returns and restores the selected
window, which is in your case the opportunity to resize the
mini-window.  When redisplay is inhibited, the code which resizes the
mini-window returns without doing anything.  So one way of fixing this
would be to try to avoid with-selected-window, and instead use some
other way of achieving what you want to do.

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't know.  You haven't actually explained what you are trying to
> accomplish and why you use this strange way of accomplishing it.  Why
> not, for example, use the minibuffer-prompt face instead to show the
> prompt in a different typeface?

In order to automatically explain certain Emacs features, I am using
Emacs to simulate interactions that would take place if the user pressed
certain keys. For this reason, I have a program that inserts text in the
minibuffer, as if the user had typed the text. In the Emacs versions I
mentioned, this works as expected: The minibuffer resizes as if the user
had typed the text. I noticed that in Emacs versions starting from 28.2,
this no longer works. For my use case, this is a regression which I
filed as an issue. I filed the issue by following the instructions:

    Please describe exactly what actions triggered the bug,
    and the precise symptoms of the bug. If you can, give a recipe
    starting from 'emacs -Q':

I kept the issue to a smallest fragment that exhibits the regression,
and it comes as a surprise to me that you now say "You haven't actually
explained what you are trying to accomplish and why you use this strange
way of accomplishing it", because such an explanation was never asked
for and also the instructions for filing an issue do not mention it.
Still, I have now provided the explanation and I hope it suffices to
explain the concrete use case I have for this feature. If you need to
know anything else to improve this case, please ask me. Thank you a lot!

> mini-window.  When redisplay is inhibited, the code which resizes the
> mini-window returns without doing anything.  So one way of fixing this
> would be to try to avoid with-selected-window, and instead use some
> other way of achieving what you want to do.

I have now tried various ways to resize the minibuffer in the situation
I posted, and so far found no way to do it. I am including a snippet
that uses fit-window-to-buffer, and does not use with-selected-window,
and still the text in the minibuffer is not fully visible. I have also
changed attributes of minibuffer-prompt, and they seem to have no effect
on the case I posted: In my use case, I deliberately use a larger face
so that the simulated minibuffer interaction is more easily readable.

If there is any other way I should try, or any way to get the minibuffer
to show the entire buffer content in the situation I mentioned, please
let me know any time, I would greatly appreciate your help with this.

Thank you a lot,
Markus


(let ((f (selected-frame)))
  (with-selected-frame (make-frame)
    (switch-to-buffer (get-buffer-create "other")))
  (select-frame-set-input-focus f)
  (let ((win (get-buffer-window "other" t)))
    (when win
      (with-selected-window win
        (recenter 0)))
    (let ((w (selected-window)))
      (unwind-protect
          (progn
            (select-window (minibuffer-window))
            (setq-local face-remapping-alist `((default :height 2.0)))
            (fit-window-to-buffer)
            (insert "hello")
            (read-key))
        (erase-buffer))
      (select-window w))))

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 67715@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 10:04:18 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't know.  You haven't actually explained what you are trying to
> > accomplish and why you use this strange way of accomplishing it.  Why
> > not, for example, use the minibuffer-prompt face instead to show the
> > prompt in a different typeface?
> 
> In order to automatically explain certain Emacs features, I am using
> Emacs to simulate interactions that would take place if the user pressed
> certain keys. For this reason, I have a program that inserts text in the
> minibuffer, as if the user had typed the text. In the Emacs versions I
> mentioned, this works as expected: The minibuffer resizes as if the user
> had typed the text. I noticed that in Emacs versions starting from 28.2,
> this no longer works. For my use case, this is a regression which I
> filed as an issue. I filed the issue by following the instructions:
> 
>     Please describe exactly what actions triggered the bug,
>     and the precise symptoms of the bug. If you can, give a recipe
>     starting from 'emacs -Q':
> 
> I kept the issue to a smallest fragment that exhibits the regression,
> and it comes as a surprise to me that you now say "You haven't actually
> explained what you are trying to accomplish and why you use this strange
> way of accomplishing it", because such an explanation was never asked
> for and also the instructions for filing an issue do not mention it.

There's nothing wrong with your original report.  I asked for
additional details to understand better what you are trying tio
accomplish, in the hope that it will facilitate ideas for working
around the problem.

I'm adding Martin to this discussion in the hope that he could have
some ideas.

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 67715@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 10:04:18 +0100
> 
> (let ((f (selected-frame)))
>   (with-selected-frame (make-frame)
>     (switch-to-buffer (get-buffer-create "other")))
>   (select-frame-set-input-focus f)
>   (let ((win (get-buffer-window "other" t)))
>     (when win
>       (with-selected-window win
>         (recenter 0)))
>     (let ((w (selected-window)))
>       (unwind-protect
>           (progn
>             (select-window (minibuffer-window))
>             (setq-local face-remapping-alist `((default :height 2.0)))
>             (fit-window-to-buffer)
>             (insert "hello")
>             (read-key))
>         (erase-buffer))
>       (select-window w))))

This seems to work:

(let ((f (selected-frame)))
  (with-selected-frame (make-frame)
    (switch-to-buffer (get-buffer-create "other")))
  (select-frame-set-input-focus f)
  (let ((win (get-buffer-window "other" t)))
    (when win
      (with-selected-window win
        (recenter 0)))
    (let ((w (selected-window)))
      (unwind-protect
          (progn
            (select-window (minibuffer-window))
            (fit-window-to-buffer)
            (read-key (propertize "hello" 'face '(:height 2.0))))
        (erase-buffer))
      (select-window w))))

As well as this (which is a minor variant of your original recipe);

    (let ((f (selected-frame)))
      (with-selected-frame (make-frame)
        (switch-to-buffer (get-buffer-create "other")))
      (select-frame-set-input-focus f)
      (let ((win (get-buffer-window "other" t)))
        (when win
          (with-selected-window win
            (recenter 0)))
        (with-selected-window (minibuffer-window)
          (unwind-protect
              (read-key (propertize "hello" 'face '(:height 2.0)))
            (erase-buffer)))))

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> This seems to work:...

Thank you a lot for looking into this! As mentioned, I am using Emacs to
simulate interactions that would take place if the user pressed certain
keys, and so I would also like to show the effects of continuous typing
in the buffer, i.e., incrementally adding or even removing text, like a
normal interaction that would take place in the minibuffer.

A condensed example of this is given in #34957, where "hello" is
followed by " there!". In my actual application, these texts are not
added in blocked chunks, but continuously letter by letter, and I can
easily do this also with a larger font by remapping the default face, in
Emacs versions before 28.2, by simply inserting the intended letters in
the minibuffer. Is there a way to implement this also in later versions
so that the program remains simple and the minibuffer is fully visible?

Thank you a lot!
Markus

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 67715@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 21:09:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This seems to work:...
> 
> Thank you a lot for looking into this! As mentioned, I am using Emacs to
> simulate interactions that would take place if the user pressed certain
> keys, and so I would also like to show the effects of continuous typing
> in the buffer, i.e., incrementally adding or even removing text, like a
> normal interaction that would take place in the minibuffer.
> 
> A condensed example of this is given in #34957, where "hello" is
> followed by " there!". In my actual application, these texts are not
> added in blocked chunks, but continuously letter by letter, and I can
> easily do this also with a larger font by remapping the default face, in
> Emacs versions before 28.2, by simply inserting the intended letters in
> the minibuffer. Is there a way to implement this also in later versions
> so that the program remains simple and the minibuffer is fully visible?

I'm not sure I understood, but if you put a face on some text, and
then type at the end of that text, the additional text you type is
supposed to "inherit" that face, no?

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure I understood, but if you put a face on some text, and
> then type at the end of that text, the additional text you type is
> supposed to "inherit" that face, no?

I mean: When my program runs, I do not type anything myself, but the
program simulates that something is being typed by me. For example, when
I ask the program to perform one step, it may simulate that M-x is
pressed, by inserting the text "M-x " in the minibuffer, and then wait
for further instructions (by me). When I then ask the program to perform
the next step, it may simulate that "emacs-uptime" is being typed, and
thus incrementally add the letters "e", "m", "a", ... to the minibuffer
while waiting for a short amount of time after each letter, until (in
total) "M-x emacs-uptime" appears in the minibuffer. The goal is that we
can simulate the effects of typing while minimizing manual effort.

This all already works as expected in Emacs versions before 28.2, and it
works to a large extent also in later versions. The only remaining
problem I have with Emacs 28.2 and later versions is that in situations
like the one I posted, the minibuffer is no longer adequately grown to
fully display the text it contains (because the program wrote it there).

With your snippet, I can work around a very specific case of this, where
a single string is shown in the minibuffer. For my use case though, this
is not yet enough, because my program simulates manual edits by changing
text in the minibuffer, such as adding or removing individual letters.

I am therefore interested in ways to grow the minibuffer so that it is
large enough, while allowing very flexible editing operations to be
simulated in it that go beyond showing a single string.

Thank you and all the best,
Markus

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: 67715@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 22:11:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure I understood, but if you put a face on some text, and
> > then type at the end of that text, the additional text you type is
> > supposed to "inherit" that face, no?
> 
> I mean: When my program runs, I do not type anything myself, but the
> program simulates that something is being typed by me. For example, when
> I ask the program to perform one step, it may simulate that M-x is
> pressed, by inserting the text "M-x " in the minibuffer, and then wait
> for further instructions (by me). When I then ask the program to perform
> the next step, it may simulate that "emacs-uptime" is being typed, and
> thus incrementally add the letters "e", "m", "a", ... to the minibuffer
> while waiting for a short amount of time after each letter, until (in
> total) "M-x emacs-uptime" appears in the minibuffer. The goal is that we
> can simulate the effects of typing while minimizing manual effort.
> 
> This all already works as expected in Emacs versions before 28.2, and it
> works to a large extent also in later versions. The only remaining
> problem I have with Emacs 28.2 and later versions is that in situations
> like the one I posted, the minibuffer is no longer adequately grown to
> fully display the text it contains (because the program wrote it there).
> 
> With your snippet, I can work around a very specific case of this, where
> a single string is shown in the minibuffer. For my use case though, this
> is not yet enough, because my program simulates manual edits by changing
> text in the minibuffer, such as adding or removing individual letters.

You could perhaps use 'message'.  Here's a trivial demo:

  (defun my-msg ()
    (interactive)
    (message (propertize "something" 'face '(:height 2.0))))
  (defun my-msg2 ()
    (interactive)
    (message (propertize "something else" 'face '(:height 2.0))))
  (global-set-key [f5] 'my-msg)
  (global-set-key [f6] 'my-msg2)

Evaluate the above, then press F5 followed by F6.

> I am therefore interested in ways to grow the minibuffer so that it is
> large enough, while allowing very flexible editing operations to be
> simulated in it that go beyond showing a single string.

I'm showing you all the methods I can come up with.  Maybe Martin or
others will have better ideas (so please don't elide their addresses
when replying).

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm adding Martin to this discussion in the hope that he could have
> some ideas.

Yes, thank you a lot Martin, I would greatly appreciate if you could
also look into this issue and help with it! For you in particular, it
may be interesting that the snippet works completely as expected if only
a single frame is present. For example, if I change the original snippet
by commenting out two lines to obtain:

    (let ((f (selected-frame)))
      ;; (with-selected-frame (make-frame)
      ;;   (switch-to-buffer (get-buffer-create "other")))
      (select-frame-set-input-focus f)
      (let ((win (get-buffer-window "other" t)))
        (when win
          (with-selected-window win
            (recenter 0)))
        (with-selected-window (minibuffer-window)
          (unwind-protect
              (progn
                (setq-local face-remapping-alist `((default :height 2.0)))
                (insert "hello")
                (read-key))
            (erase-buffer)))))

then "hello" is fully visible in the minibuffer, as expected! The
existence and prior, even only temporary, selection of another frame
unexpectedly prevents the entire minibuffer content to be shown. My
expectation would be for another frame to have no influence here.

Thank you and all the best,
Markus

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

> From: Markus Triska <triska@metalevel.at>
> Cc: martin rudalics <rudalics@gmx.at>,  67715@debbugs.gnu.org
> Date: Sun, 10 Dec 2023 09:12:28 +0100
> 
> then "hello" is fully visible in the minibuffer, as expected! The
> existence and prior, even only temporary, selection of another frame
> unexpectedly prevents the entire minibuffer content to be shown. My
> expectation would be for another frame to have no influence here.

The other frame affects this because when redisplay redraws a frame,
it temporarily selects that frame, and that selection can resize the
mini-window, something that Lisp programs don't expect to happen.  To
prevent such unwarranted resizing, we disabled it while any other
frame is temporarily selected.  See bug#24285.

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm showing you all the methods I can come up with.  Maybe Martin or
> others will have better ideas (so please don't elide their addresses
> when replying).

Yes thank you and Martin! Here is an example of my use case, using a
slight generalization of the original snippet:

    (let ((f (selected-frame)))
      ;; (with-selected-frame (make-frame)
      ;;   (switch-to-buffer (get-buffer-create "other")))
      (select-frame-set-input-focus f)
      (let ((win (get-buffer-window "other" t)))
        (when win
          (with-selected-window win
            (recenter 0)))
        (with-selected-window (minibuffer-window)
          (unwind-protect
              (progn
                (setq-local face-remapping-alist `((default :height 2.0)))
                (insert "M-x ")
                (read-key)
                (let ((chars (string-to-list "emacs-uptime")))
                  (while chars
                    (insert (char-to-string (pop chars)))
                    (when chars
                      (sit-for 0.3))))
                (read-key))
            (erase-buffer)))))

The snippet simulates what occurs if I were to press M-x, by inserting
"M-x " in the minibuffer. It then waits for a key press. After I press a
key, it simulates what would occur if I were to type emacs-uptime, by
writing "emacs-uptime" in the minibuffer in such a way that the
minibuffer content changes as if someone typed that command.

It all works as intended in all Emacs versions I tried, except if I
uncomment the two lines that are commented out in the snippet above:
Then, Emacs 28.2 and later versions no longer show the minibuffer fully.

Thank you and all the best,
Markus

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > I'm adding Martin to this discussion in the hope that he could have
 > some ideas.

I've been going back through your earlier comments and found:

 > The basic technical reason for what you see is that redisplay is
 > inhibited when with-selected-window returns and restores the selected
 > window, which is in your case the opportunity to resize the
 > mini-window.  When redisplay is inhibited, the code which resizes the
 > mini-window returns without doing anything.  So one way of fixing this
 > would be to try to avoid with-selected-window, and instead use some
 > other way of achieving what you want to do.

I doubt that this is the problem because

(let ((f (selected-frame)))
   (with-current-buffer (get-buffer-create "other")
     (make-frame))
   (select-frame-set-input-focus f)
   (with-current-buffer (window-buffer (minibuffer-window))
     (unwind-protect
         (progn
           (setq-local face-remapping-alist `((default :height 2.0)))
           (insert "hello")
	  (read-key))
       (erase-buffer))))

doesn't resize the minibuffer either.  IIUC Markus was just lucky that
this worked earlier because then the frame title code resized the
minibuffer window.  After the fix of Bug#24285 it doesn't do that any
more.

martin

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Markus Triska]

martin rudalics <rudalics@gmx.at> writes:

> I doubt that this is the problem because

Thank you a lot Martin for looking into this. To clarify: Does the
cause of this issue, which is different from the one that was originally
stated, mean that issue I have filed here and which still persists can
be fixed while the other mentioned problem is also addressed correctly?

For my use cases, I would greatly appreciate if this worked again.

Thank you and all the best,
Markus

bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors]

 > Thank you a lot Martin for looking into this. To clarify: Does the
 > cause of this issue, which is different from the one that was originally
 > stated, mean that issue I have filed here and which still persists can
 > be fixed while the other mentioned problem is also addressed correctly?

IIUC the code that previously calculated the frame title could resize
the minibuffer window and, while doing that, redisplay its contents in
your sense.  After the fix, it doesn't do that any more.

IMO, code calculating things like the mode line contents or the frame
title should be completely transparent.  It should affect only the
contents of the mode line or the frame title.  Anything else would be a
misfeature.  So I doubt that any future changes in that code will
address your problem.

I'd first try to add some :eval form to 'frame-title-format' that binds
‘inhibit-redisplay’ to nil and maybe resizes the minibuffer window so it
gets redisplayed to show the contents of its buffer in your sense.

martin