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

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm afraid that the very existence of prevent_redisplay_optimizations_p
>> flag is a mistake hiding bugs with redisplay optimizations logic.
>
> I think you should avoid making such comments until you have a better
> understanding of the redisplay logic, or else I will stop taking your
> posts in this matter seriously.

Your answer indicates that I missed something important after reading
the top comment in xdisp.c, redisplay_internal, redisplay_window, and
skimmed through a couple of other functions. But I still cannot figure
out what.

Note that I did not mean that previous committers had bad intentions. I
just think that the idea of having "disable all optimizations" flag is
causing the code quality that could be otherwise somewhat better (at
least, more explicit about why redisplay should take long path).

I think that replacing all the instances of setting this flag to more
explicit alternatives would improve the display performance and also
readability.

>> Currently, redisplay_internal has a number of conditions used to
>> determine if one or another optimization is safe to use + assertion that
>> !prevent_redisplay_optimizations_p.
>> 
>> When some code outside xdisp.c sets this flag, it is nothing but a
>> statement: "I was lazy enough to update xdisp.c properly, so I just
>> force bypassing optimizations".
>
> No.  The optimization in question, which is disabled when
> prevent_redisplay_optimizations_p flag is set for the current buffer,
> is described in the comment before the condition:
>
>   /* Optimize the case that only the line containing the cursor in the
>      selected window has changed.
>
> The prevent_redisplay_optimizations_p flag says, among other things,
> that we are not in that case, and it is tested early enough in order
> to prevent us from examining additional conditions which are just
> waste of CPU cycles (and some of them are relatively expensive).

Sure, but it is a very generic way to say this. It provides no detailed
reason what exactly changed in the buffer/window/frame that makes us
bypass this optimization.

Is it not always possible to use the other, more specific, existing
flags for redisplay to indicate that something important has been changed?

>> So, I see not why calling bset_update_mode_line is not sufficient to
>> force mode line update in all windows associated with a single buffer.
>
> The mode line displays quite a lot of information.  It could also
> display information we don't know about (on the level of the redisplay
> code), because mode-line-format supports :eval, which can execute any
> Lisp.  Therefore, there could be changes to the buffer that affect the
> mode line indirectly.

But isn't :eval processed by display_mode_lines? Once we take care to call
bset_update_mode_line, display_mode_lines is guaranteed to be executed,
AFAIU.

> One problem of this kind which we had relatively recently is when the
> changes in mode-line-format or some of its :eval forms yields a mode
> line that is significantly taller or smaller than the previously
> displayed one.  Such changes in the mode-line height generally affect
> the window(s) as well, not just the mode line itself.

Sure, and redisplay_window accounts for this when calling display_mode_lines:

      display_mode_lines (w);
      unbind_to (count1, Qnil);

      /* If mode line height has changed, arrange for a thorough
	 immediate redisplay using the correct mode line height.  */
      if (window_wants_mode_line (w)
	  && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
	{
	  f->fonts_changed = true;
	  w->mode_line_height = -1;
	  MATRIX_MODE_LINE_ROW (w->current_matrix)->height
	    = DESIRED_MODE_LINE_HEIGHT (w);
	}

> Moreover, you will see in the wild that force-mode-line-update is used
> not just to update the mode line, but also to force a more thorough
> redisplay of one or more windows.

Why not `force-window-update'? 

> Thus, this is not as simple a problem as you seem to think, and we
> need deeper analysis and more significant changes than simply deleting
> the code that you didn't understand and think is redundant.  Please
> keep in mind that people who wrote that code (and I don't mean myself)
> were not stupid at all, and generally knew what they were doing!

I understand, which is why I looked into git history and found that the
code in question is carried over during refactoring. Into a new function
with different meaning.

And I now looked deeper into the code, and see no obvious downsides of
removing current_buffer->prevent_redisplay_optimizations_p = true; from
force-mode-line-update specifically.
`set-buffer-modified-p' may need to be re-considered though as it is the
original place where setting prevent_redisplay_optimizations_p was done
(for different reasons).

>> > The purpose of force-mode-line-update is to do what its name says,
>> ... 
>> Then, why do we need to call Fforce_mode_line_update in
>> set-buffer-modified-p? Wouldn't calling bset_redisplay be better?
>
> You have read the large comment there which attempts to answer this
> question, didn't you?

Yup, I did. I thought bset_redisplay as an alternative, because it is
smarter than bset_update_mode_line when the buffer is displayed in
selected window (it is not necessary to assign DISPLAY_SOME flags).

However, I did miss the docstring that explicitly says that
`set-buffer-modified-p' forces mode line update. So, forcing mode line
update here is simply following the docstring and should not be
disputed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>