bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-upda


From: Eli Zaretskii
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Date: Sun, 16 Jul 2023 11:50:14 +0300

> Date: Sun, 16 Jul 2023 10:26:04 +0200
> Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  From the POV of window management the situation is simple: When the size
> of a window or a decoration changes, it would like to tell redisplay
> about it.  But redisplay would have to tell it first which kind of
> changes it's able to accept.

I don't think this is required.  The information flow is
unidirectional: the functions which change the windows should tell
what they changed, and redisplay will then decide what that requires.
For example, if some windows changed their dimensions, redisplay would
need to know which dimension changed.

> For example, I don't even know whether, when running without window
> matrices, redisplay is capable of doing something reasonable with
> the fact that the border between two adjacent windows shifted and a
> third window not affected by that shift can be spared by redisplay.

If the third window displays a buffer that didn't change in any way,
then yes, the display engine should be capable of doing the above.  On
TTY frames, the display engine considers the entire frame, so it
should see that the portion corresponding to that third window didn't
change, and refrain from redrawing it.

> As an example: one of the worst things the window code does is saving a
> window configuration, reading something from the minibuffer and
> restoring the window configuration when done.  In nine out of ten cases
> the restored configuration will not have changed and redisplay wouldn't
> have to do anything.  Now Fset_window_configuration is awful in the
> regard that it deletes all windows on the frame regardless of whether
> the configuration changed only to "restore" them later (including that
> n_leaf_windows allocation hack to find out which glyph matrices can be
> safely freed).  While it is fairly easy to fix that, it's by no means
> clear what and how to tell redisplay that some window did change in one
> of those rare cases where it did.

We need to add flags that convey the information about which windows
changed what dimensions.

> (let (config)
>    (set-frame-parameter nil 'left-fringe 50)
>    (y-or-n-p "?")
>    (setq config (current-window-configuration))
>    (setq left-fringe-width 0)
>    (set-window-buffer nil (window-buffer))
>    (y-or-n-p "?")
>    (set-window-configuration config))
> 
> Here 'set-window-configuration' should be able to tell redisplay that it
> should redisplay the window but it should be able to tell that iff the
> fringe really changed which is fairly easy to find out.  Once it found
> out, which kind of flag would it set?

I'm not even sure it must find that out.  It could simply tell
redisplay that the fringe really changed.  The rest is up to the
display engine to decide.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]