GNU bug report logs - #67715
28.2; Minibuffer content is sometimes unexpectedly partially hidden

Previous Next

Full log

Message #19 received at 67715 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67715 <at> debbugs.gnu.org
Subject: Re: bug#67715: 28.2;
 Minibuffer content is sometimes unexpectedly partially hidden
Date: Sat, 09 Dec 2023 10:04:18 +0100

Eli Zaretskii <eliz <at> 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))))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.