From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luangruo@yahoo.com, rahguzar@zohomail.eu, r.diaz@uam.es,
rdiaz02@gmail.com, 70038@debbugs.gnu.org
Subject: bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts
Date: Mon, 8 Apr 2024 11:07:50 +0200 [thread overview]
Message-ID: <028e677b-6d6b-42b2-95ac-0e0c5d1f3dd1@gmx.at> (raw)
In-Reply-To: <8634rx1kfb.fsf@gnu.org>
IIUC the basic idea of all this is to preserve window start positions
when enlarging a mini window unless that would move a window's point
outside that window. Once upon a time, resize_mini_window used window
configurations to get back the previous start positions but that was
maybe considered too costly and Gerd decided to "Don't save window
configuration, freeze window starts instead."
A possibly heretical question is in which way freezing start positions
permanently can harm. IIUC, after a minibuffer interaction, currently
the only way to unfreeze start positions is to resize the minibuffer
window and trigger the corresponding call in shrink_mini_window. But
setting the start position of any window while a minibuffer interaction
is going on seems to work here without problems.
Let's assume it can harm:
>> If the only
>> problem is that of restore_window_configuration, then minibuffer_unwind
>> looks like the right place.
That was silly. minibuffer_unwind seems to care only about replacing
one minibuffer with another. read_minibuf_unwind already should handle
this here (don't ask me what a future_mini_window is)
/* When we get to the outmost level, make sure we resize the
mini-window back to its normal size. */
if (minibuf_level == 0
|| !EQ (selected_frame, WINDOW_FRAME (XWINDOW (future_mini_window))))
resize_mini_window (XWINDOW (minibuf_window), 0);
The only problem is that if the mini window was _not_ enlarged,
shrink_mini_window won't unfreeze starts. Unconditionally unfreezing
start positions there as I mentioned in my first mail should fix that.
> Hmm... read_char_help_form_unwind is called after we invoke
> help-form-show, and that one pops up a special buffer:
>
> (defun help-form-show ()
> "Display the output of a non-nil `help-form'."
> (let ((msg (eval help-form t)))
> (if (stringp msg)
> (with-output-to-temp-buffer " *Char Help*"
> (princ msg)))))
>
> Is there a way to make that use the echo-area? if so, can you tell how
> to do that?
IIUC that is called in a situation where the minibuffer is active.
Showing that text in the echo area (albeit shortly) doesn't look like
TRT to me.
IIUC read_char can resize the mini window here
if (minibuf_level
&& EQ (minibuf_window, echo_area_window)
/* The case where minibuffer-message-timeout is a number
was already handled near the beginning of command_loop_1. */
&& !NUMBERP (Vminibuffer_message_timeout))
resize_mini_window (XWINDOW (minibuf_window), false);
so this should be covered by read_minibuf_unwind already.
martin
next prev parent reply other threads:[~2024-04-08 9:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 20:25 bug#70038: 29.3.50; Shift up/down in buffer with images on M-x other-window with some fonts Ramon Diaz-Uriarte
2024-03-28 5:58 ` Eli Zaretskii
2024-03-28 7:52 ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 8:36 ` Eli Zaretskii
2024-03-28 16:12 ` Ramon Diaz-Uriarte
2024-03-28 16:59 ` Ramon Diaz-Uriarte
2024-03-28 17:24 ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-28 19:50 ` Rahguzar via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-31 18:43 ` Ramon Diaz-Uriarte
2024-04-06 12:33 ` Eli Zaretskii
2024-04-06 14:08 ` Eli Zaretskii
2024-04-06 14:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 8:24 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 9:13 ` Eli Zaretskii
2024-04-07 10:12 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-07 11:28 ` Eli Zaretskii
2024-04-08 9:07 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-04-13 10:10 ` Eli Zaretskii
2024-04-14 8:31 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-14 9:28 ` Eli Zaretskii
2024-04-15 9:23 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-15 13:54 ` Eli Zaretskii
2024-04-17 8:02 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-17 12:58 ` Eli Zaretskii
2024-04-28 8:51 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-28 9:15 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 9:47 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 12:51 ` Eli Zaretskii
2024-04-11 13:56 ` Ramon Diaz-Uriarte
2024-04-11 15:36 ` Eli Zaretskii
2024-04-12 16:43 ` Ramon Diaz-Uriarte
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=028e677b-6d6b-42b2-95ac-0e0c5d1f3dd1@gmx.at \
--to=bug-gnu-emacs@gnu.org \
--cc=70038@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=luangruo@yahoo.com \
--cc=r.diaz@uam.es \
--cc=rahguzar@zohomail.eu \
--cc=rdiaz02@gmail.com \
--cc=rudalics@gmx.at \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.