Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Eli Zaretskii]

> Author:     Po Lu <luangruo@yahoo.com>
> AuthorDate: Mon Apr 18 13:23:23 2022 +0800
> Commit:     Po Lu <luangruo@yahoo.com>
> CommitDate: Mon Apr 18 13:23:23 2022 +0800
> 
>     Fix glyph skipping optimization when a tab line is enabled
> 
>     * src/dispnew.c (update_text_area): Compute vpos of header line
>     correctly when window has tab line.
> 
> diff --git a/src/dispnew.c b/src/dispnew.c
> index 0d95904..3cfe1b8 100644
> --- a/src/dispnew.c
> +++ b/src/dispnew.c
> @@ -3928,9 +3928,12 @@ update_text_area (struct window *w, struct glyph_row *upd
>          However, it causes excessive flickering when mouse is moved
>          across the mode line.  Luckily, turning it off for the mode
>          line doesn't seem to hurt anything. -- cyd.
> -         But it is still needed for the header line. -- kfs.  */
> +         But it is still needed for the header line. -- kfs.
> +         The header line vpos is 1 if a tab line is enabled.  (18th
> +         Apr 2022) */
>        || (current_row->mouse_face_p
> -         && !(current_row->mode_line_p && vpos > 0))
> +         && !(current_row->mode_line_p
> +              && (vpos > w->current_matrix->tab_line_p)))
>        || current_row->x != desired_row->x)
>      {
>        output_cursor_to (w, vpos, 0, desired_row->y, desired_row->x);

I'm not sure I understand this change.  What exactly is the problem,
and how to reproduce it?  What if there's no header-line, but there is
a tab-line, or vice versa, or both are displayed?  And why mentioning
the date of the change in the comment?

Thanks.

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Author:     Po Lu <luangruo@yahoo.com>
>> AuthorDate: Mon Apr 18 13:23:23 2022 +0800
>> Commit:     Po Lu <luangruo@yahoo.com>
>> CommitDate: Mon Apr 18 13:23:23 2022 +0800
>> 
>>     Fix glyph skipping optimization when a tab line is enabled
>> 
>>     * src/dispnew.c (update_text_area): Compute vpos of header line
>>     correctly when window has tab line.
>> 
>> diff --git a/src/dispnew.c b/src/dispnew.c
>> index 0d95904..3cfe1b8 100644
>> --- a/src/dispnew.c
>> +++ b/src/dispnew.c
>> @@ -3928,9 +3928,12 @@ update_text_area (struct window *w, struct glyph_row *upd
>>          However, it causes excessive flickering when mouse is moved
>>          across the mode line.  Luckily, turning it off for the mode
>>          line doesn't seem to hurt anything. -- cyd.
>> -         But it is still needed for the header line. -- kfs.  */
>> +         But it is still needed for the header line. -- kfs.
>> +         The header line vpos is 1 if a tab line is enabled.  (18th
>> +         Apr 2022) */
>>        || (current_row->mouse_face_p
>> -         && !(current_row->mode_line_p && vpos > 0))
>> +         && !(current_row->mode_line_p
>> +              && (vpos > w->current_matrix->tab_line_p)))
>>        || current_row->x != desired_row->x)
>>      {
>>        output_cursor_to (w, vpos, 0, desired_row->y, desired_row->x);
>
> I'm not sure I understand this change.  What exactly is the problem,
> and how to reproduce it?  What if there's no header-line, but there is
> a tab-line, or vice versa, or both are displayed?

Not sure, but the previous code would also trigger for just tab lines,
but not also the header line if there was a tab line.

Here is how to reproduce the problem this fixes: turn on
global-tab-line-mode, open Info, type "m cl RET g Predicates RET", then
click on the "e" in the "Next: Control Structure" link on the header
line.  "Next:" will continue to be displayed in the mouse face even
though the mouse is no longer on any link, due to the "glyph-skipping"
optimization that is normally disabled for the header and tab lines
being used.

Thanks.

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Apr 2022 15:32:42 +0800
> 
> >> diff --git a/src/dispnew.c b/src/dispnew.c
> >> index 0d95904..3cfe1b8 100644
> >> --- a/src/dispnew.c
> >> +++ b/src/dispnew.c
> >> @@ -3928,9 +3928,12 @@ update_text_area (struct window *w, struct glyph_row *upd
> >>          However, it causes excessive flickering when mouse is moved
> >>          across the mode line.  Luckily, turning it off for the mode
> >>          line doesn't seem to hurt anything. -- cyd.
> >> -         But it is still needed for the header line. -- kfs.  */
> >> +         But it is still needed for the header line. -- kfs.
> >> +         The header line vpos is 1 if a tab line is enabled.  (18th
> >> +         Apr 2022) */
> >>        || (current_row->mouse_face_p
> >> -         && !(current_row->mode_line_p && vpos > 0))
> >> +         && !(current_row->mode_line_p
> >> +              && (vpos > w->current_matrix->tab_line_p)))
> >>        || current_row->x != desired_row->x)
> >>      {
> >>        output_cursor_to (w, vpos, 0, desired_row->y, desired_row->x);
> >
> > I'm not sure I understand this change.  What exactly is the problem,
> > and how to reproduce it?  What if there's no header-line, but there is
> > a tab-line, or vice versa, or both are displayed?
> 
> Not sure, but the previous code would also trigger for just tab lines,
> but not also the header line if there was a tab line.
> 
> Here is how to reproduce the problem this fixes: turn on
> global-tab-line-mode, open Info, type "m cl RET g Predicates RET", then
> click on the "e" in the "Next: Control Structure" link on the header
> line.  "Next:" will continue to be displayed in the mouse face even
> though the mouse is no longer on any link, due to the "glyph-skipping"
> optimization that is normally disabled for the header and tab lines
> being used.

OK, and what about the last question I asked above?  If there's no
header-line, but there is a tab-line, the code will still compare vpos
with 1, although the vpos of the tab-line is now zero, right?

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, and what about the last question I asked above?  If there's no
> header-line, but there is a tab-line, the code will still compare vpos
> with 1, although the vpos of the tab-line is now zero, right?

I see how the code might be made clearer if the assumption that a mode
line cannot be at vpos 1 isn't made, but can a mode line (the other kind
of mode_line_p row there is) really be at vpos 1?  Aren't windows
required to have a body height of at least 1 line?

Thanks.

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Apr 2022 15:53:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > OK, and what about the last question I asked above?  If there's no
> > header-line, but there is a tab-line, the code will still compare vpos
> > with 1, although the vpos of the tab-line is now zero, right?
> 
> I see how the code might be made clearer if the assumption that a mode
> line cannot be at vpos 1 isn't made, but can a mode line (the other kind
> of mode_line_p row there is) really be at vpos 1?  Aren't windows
> required to have a body height of at least 1 line?

Maybe not, but why should such subtle assumptions be implicitly
embedded in the code, when you have specific flags to do the job?  A
glyph matrix has both header_line_p and tab_line_p flags, so comparing
to their sum should do the job cleanly, I think.  Or am I missing
something?

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe not, but why should such subtle assumptions be implicitly
> embedded in the code, when you have specific flags to do the job?  A
> glyph matrix has both header_line_p and tab_line_p flags, so comparing
> to their sum should do the job cleanly, I think.

Yes, I already installed such a change, but I asked that question for
future reference.

Thanks.

Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 18 Apr 2022 16:23:34 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe not, but why should such subtle assumptions be implicitly
> > embedded in the code, when you have specific flags to do the job?  A
> > glyph matrix has both header_line_p and tab_line_p flags, so comparing
> > to their sum should do the job cleanly, I think.
> 
> Yes, I already installed such a change, but I asked that question for
> future reference.

I think the answer is YES, but the condition is enforced in window.el,
so it isn't necessarily "carved in stone".