unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
@ 2022-04-18  7:18 Eli Zaretskii
  2022-04-18  7:32 ` Po Lu
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-04-18  7:18 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
  2022-04-18  7:18 master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled Eli Zaretskii
@ 2022-04-18  7:32 ` Po Lu
  2022-04-18  7:41   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Po Lu @ 2022-04-18  7:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
  2022-04-18  7:32 ` Po Lu
@ 2022-04-18  7:41   ` Eli Zaretskii
  2022-04-18  7:53     ` Po Lu
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-04-18  7:41 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
  2022-04-18  7:41   ` Eli Zaretskii
@ 2022-04-18  7:53     ` Po Lu
  2022-04-18  8:17       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Po Lu @ 2022-04-18  7:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
  2022-04-18  7:53     ` Po Lu
@ 2022-04-18  8:17       ` Eli Zaretskii
  2022-04-18  8:23         ` Po Lu
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-04-18  8:17 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
  2022-04-18  8:17       ` Eli Zaretskii
@ 2022-04-18  8:23         ` Po Lu
  2022-04-18  9:18           ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Po Lu @ 2022-04-18  8:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled
  2022-04-18  8:23         ` Po Lu
@ 2022-04-18  9:18           ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2022-04-18  9:18 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-04-18  9:18 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-04-18  7:18 master 5b5608c614: Fix glyph skipping optimization when a tab line is enabled Eli Zaretskii
2022-04-18  7:32 ` Po Lu
2022-04-18  7:41   ` Eli Zaretskii
2022-04-18  7:53     ` Po Lu
2022-04-18  8:17       ` Eli Zaretskii
2022-04-18  8:23         ` Po Lu
2022-04-18  9:18           ` Eli Zaretskii

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