unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Markus Triska <triska@metalevel.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 67715@debbugs.gnu.org
Subject: bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden
Date: Sat, 09 Dec 2023 10:04:18 +0100	[thread overview]
Message-ID: <878r63vjal.fsf@metalevel.at> (raw)
In-Reply-To: <83wmtnyffx.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Dec 2023 09:59:14 +0200")

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))))





  reply	other threads:[~2023-12-09  9:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 19:03 bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden Markus Triska
2023-12-08 20:35 ` Eli Zaretskii
2023-12-09  7:04   ` Markus Triska
2023-12-09  7:59     ` Eli Zaretskii
2023-12-09  9:04       ` Markus Triska [this message]
2023-12-09 11:18         ` Eli Zaretskii
2023-12-10  8:12           ` Markus Triska
2023-12-10  9:27             ` Eli Zaretskii
2023-12-11 17:12           ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-14  7:43             ` Markus Triska
2024-01-14  8:49               ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 17:02         ` Eli Zaretskii
2023-12-09 20:09           ` Markus Triska
2023-12-09 20:20             ` Eli Zaretskii
2023-12-09 21:11               ` Markus Triska
2023-12-10  5:44                 ` Eli Zaretskii
2023-12-10 17:59                   ` Markus Triska

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878r63vjal.fsf@metalevel.at \
    --to=triska@metalevel.at \
    --cc=67715@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).