unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: luangruo@yahoo.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: Sat, 13 Apr 2024 13:10:32 +0300	[thread overview]
Message-ID: <86jzl1po87.fsf@gnu.org> (raw)
In-Reply-To: <028e677b-6d6b-42b2-95ac-0e0c5d1f3dd1@gmx.at> (message from martin rudalics on Mon, 8 Apr 2024 11:07:50 +0200)

> Date: Mon, 8 Apr 2024 11:07:50 +0200
> Cc: r.diaz@uam.es, luangruo@yahoo.com, rahguzar@zohomail.eu,
>  rdiaz02@gmail.com, 70038@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
> 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.

The (slight) harm this does is that it might make redisplay of the
window slightly more expensive, because it disables some
optimizations, like if nothing changed except the position of point.
Another kind of harm is what triggered this bug report: it could cause
us to reset the window's vscroll for now good reason, because when
start positions are frozen, we set the window's force_start flag, and
that sometimes forces us to reset vscroll.

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

Thanks.

So the patch below is the only change we need to make sure the frame's
frozen_window_starts is reset when the mini-window is resized back?

Should it matter whether, if the minibuffer is active, we do that only
at the outer level of minibuffer?

diff --git a/src/window.c b/src/window.c
index fe26311..0945b24 100644
--- a/src/window.c
+++ b/src/window.c
@@ -5407,13 +5407,13 @@ shrink_mini_window (struct window *w)
 
   eassert (MINI_WINDOW_P (w));
 
+  FRAME_WINDOWS_FROZEN (f) = false;
   if (delta > 0)
     {
       Lisp_Object root = FRAME_ROOT_WINDOW (f);
       struct window *r = XWINDOW (root);
       Lisp_Object grow;
 
-      FRAME_WINDOWS_FROZEN (f) = false;
       grow = call3 (Qwindow__resize_root_window_vertically,
 		    root, make_fixnum (delta), Qt);
 





  reply	other threads:[~2024-04-13 10:10 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
2024-04-13 10:10                       ` Eli Zaretskii [this message]
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

  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=86jzl1po87.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=70038@debbugs.gnu.org \
    --cc=luangruo@yahoo.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 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).