bug#52324: 29.0.50; "Padded" mode line lacks uniform border

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Protesilaos Stavrou]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

Dear maintainers,

In an emacs -Q session with version 27 we could evaluate the following
to make the mode line look more spacious ("padded", so to speak):

    (setq x-underline-at-descent-line t)

    (set-face-attribute 'mode-line nil
                        :foreground "black"
                        :background "gray80"
                        :box '(:line-width 6 :color "gray80")
                        :overline "gray30"
                        :underline "gray30"
                        :distant-foreground 'unspecified)

Whereas with master, the same results in a box with interrupted lines.

I attach screenshots, for your convenience.

* The emacs-27-mode-line-padded.png shows how it used to work on Emacs
  27.

* The emacs-29-mode-line-padded.png exhibits the current stylistic
  inconsistency.

Furthermore, there exists an invisible button (?) to the left of the
"All" text.  The emacs-29-mode-line-padded-mouse-pointer-button.png
shows it and also captures the tooltip.  (Maybe these are related to the
same underlying change on how the mode line is produced, otherwise I can
file a separate bug report).

All the best,
Protesilaos

-- 
Protesilaos Stavrou
https://protesilaos.com

[-- Attachment #2: emacs-27-mode-line-padded.png --]
[-- Type: image/png, Size: 63625 bytes --]

[-- Attachment #3: emacs-29-mode-line-padded.png --]
[-- Type: image/png, Size: 63673 bytes --]

[-- Attachment #4: emacs-29-mode-line-padded-mouse-pointer-button.png --]
[-- Type: image/png, Size: 67660 bytes --]

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Eli Zaretskii]

> From: Protesilaos Stavrou <info@protesilaos.com>
> Date: Mon, 06 Dec 2021 10:58:02 +0200
> 
> In an emacs -Q session with version 27 we could evaluate the following
> to make the mode line look more spacious ("padded", so to speak):
> 
>     (setq x-underline-at-descent-line t)
> 
>     (set-face-attribute 'mode-line nil
>                         :foreground "black"
>                         :background "gray80"
>                         :box '(:line-width 6 :color "gray80")
>                         :overline "gray30"
>                         :underline "gray30"
>                         :distant-foreground 'unspecified)
> 
> Whereas with master, the same results in a box with interrupted lines.

This seems to be a general bug regarding display of stretches of
whitespace with overline and underline.  In Emacs 27, after evaluating
the above settings, try this:

   M-: (setq mode-line-format "%b		%p HELLO") RET

where the whitespace between %b and %p is 2 TAB characters.  you will
see that the stretch glyph produced for the TABs lacks the overline
and underline in Emacs 27 as well.

So this is not a bug introduced by the recent changes in the mode
line, it is a bug that was always in Emacs, and those recent changes
just exposed it.

I'll try to dig into this when I have time.

> Furthermore, there exists an invisible button (?) to the left of the
> "All" text.  The emacs-29-mode-line-padded-mouse-pointer-button.png
> shows it and also captures the tooltip.  (Maybe these are related to the
> same underlying change on how the mode line is produced, otherwise I can
> file a separate bug report).

I think that's a separate bug, so please file a separate report for
it.

Thanks.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Protesilaos Stavrou]

On 2021-12-06, 16:47 +0200, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Protesilaos Stavrou <info@protesilaos.com>
>> Date: Mon, 06 Dec 2021 10:58:02 +0200
>> 
>> In an emacs -Q session with version 27 we could evaluate the following
>> to make the mode line look more spacious ("padded", so to speak):
>> 
>>     (setq x-underline-at-descent-line t)
>> 
>>     (set-face-attribute 'mode-line nil
>>                         :foreground "black"
>>                         :background "gray80"
>>                         :box '(:line-width 6 :color "gray80")
>>                         :overline "gray30"
>>                         :underline "gray30"
>>                         :distant-foreground 'unspecified)
>> 
>> Whereas with master, the same results in a box with interrupted lines.
>
> This seems to be a general bug regarding display of stretches of
> whitespace with overline and underline.  In Emacs 27, after evaluating
> the above settings, try this:
>
>    M-: (setq mode-line-format "%b		%p HELLO") RET
>
> where the whitespace between %b and %p is 2 TAB characters.  you will
> see that the stretch glyph produced for the TABs lacks the overline
> and underline in Emacs 27 as well.
>
> So this is not a bug introduced by the recent changes in the mode
> line, it is a bug that was always in Emacs, and those recent changes
> just exposed it.
>
> I'll try to dig into this when I have time.

I see.  Thanks!

>> Furthermore, there exists an invisible button (?) to the left of the
>> "All" text.  The emacs-29-mode-line-padded-mouse-pointer-button.png
>> shows it and also captures the tooltip.  (Maybe these are related to the
>> same underlying change on how the mode line is produced, otherwise I can
>> file a separate bug report).
>
> I think that's a separate bug, so please file a separate report for
> it.

Did that in bug#52332.

-- 
Protesilaos Stavrou
https://protesilaos.com

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Eli Zaretskii]

> Date: Mon, 06 Dec 2021 16:47:17 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 52324@debbugs.gnu.org
> 
> > From: Protesilaos Stavrou <info@protesilaos.com>
> > Date: Mon, 06 Dec 2021 10:58:02 +0200
> > 
> > In an emacs -Q session with version 27 we could evaluate the following
> > to make the mode line look more spacious ("padded", so to speak):
> > 
> >     (setq x-underline-at-descent-line t)
> > 
> >     (set-face-attribute 'mode-line nil
> >                         :foreground "black"
> >                         :background "gray80"
> >                         :box '(:line-width 6 :color "gray80")
> >                         :overline "gray30"
> >                         :underline "gray30"
> >                         :distant-foreground 'unspecified)
> > 
> > Whereas with master, the same results in a box with interrupted lines.
> 
> This seems to be a general bug regarding display of stretches of
> whitespace with overline and underline.  In Emacs 27, after evaluating
> the above settings, try this:
> 
>    M-: (setq mode-line-format "%b		%p HELLO") RET
> 
> where the whitespace between %b and %p is 2 TAB characters.  you will
> see that the stretch glyph produced for the TABs lacks the overline
> and underline in Emacs 27 as well.
> 
> So this is not a bug introduced by the recent changes in the mode
> line, it is a bug that was always in Emacs, and those recent changes
> just exposed it.
> 
> I'll try to dig into this when I have time.

Lu, can you help?  This has something to do with clipping, because the
overline disappears in this call to x_reset_clip_rectangles at the end
of x_draw_glyph_string:


  /* Reset clipping.  */
  x_reset_clip_rectangles (s->f, s->gc);  <<<<<<<<<<<<<<<<<<<<<<<<<
  s->num_clips = 0;

Before that call, I see the overline and underline of the stretch
glyph on the mode line as expected.  But I cannot understand what is
missing to avoid this removal of the overline and underline.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Lu, can you help?  This has something to do with clipping, because the
> overline disappears in this call to x_reset_clip_rectangles at the end
> of x_draw_glyph_string:
>
>
>   /* Reset clipping.  */
>   x_reset_clip_rectangles (s->f, s->gc);  <<<<<<<<<<<<<<<<<<<<<<<<<
>   s->num_clips = 0;
>
> Before that call, I see the overline and underline of the stretch
> glyph on the mode line as expected.  But I cannot understand what is
> missing to avoid this removal of the overline and underline.

That's a red herring.  The problem is that the box (which is already
present on the mode-line face) is drawn after the overline on top of
non-character and non-composition glyph strings, such as stretch
strings.

The correct solution is to move this code:

      /* Draw relief if not yet drawn.  */
      if (!relief_drawn_p && s->face->box != FACE_NO_BOX)
	x_draw_glyph_string_box (s);

To run before drawing the overline.  I tested and it works here, so if
you have no objections I will make that change in xterm and on the other
*terms as well.

Protesilaos, you should also turn off
x-use-underline-position-properties; otherwise, the underline will
appear somewhere inside the modeline and not underneath it.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> The correct solution is to move this code:
>
>       /* Draw relief if not yet drawn.  */
>       if (!relief_drawn_p && s->face->box != FACE_NO_BOX)
> 	x_draw_glyph_string_box (s);
>
> To run before drawing the overline.  I tested and it works here, so if
> you have no objections I will make that change in xterm and on the other
> *terms as well.

BTW, the Haiku port has the same problem, but with a very different
cause, even though text decorations are already drawn after the box:
drawing the box on such glyphs sets a special kind of graphics clipping
that prevents anything from being displayed on top of the box
afterwards.

This is done for a variety of subtle reasons that are too complicated to
explain here.

To solve it there, I made the subroutine in charge of displaying the box
draw text decorations before setting the special clipping.  It's TRT, as
everything said clipping is supposed to prevent happens after it
returns.

So as a heads up, please don't take the changes made to the Haiku port
as representative of how to solve this problem.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: info@protesilaos.com,  52324@debbugs.gnu.org
> Date: Sun, 12 Dec 2021 08:58:32 +0800
> 
> The correct solution is to move this code:
> 
>       /* Draw relief if not yet drawn.  */
>       if (!relief_drawn_p && s->face->box != FACE_NO_BOX)
> 	x_draw_glyph_string_box (s);
> 
> To run before drawing the overline.  I tested and it works here, so if
> you have no objections I will make that change in xterm and on the other
> *terms as well.

In w32term.c, I needed to place it before the drawing of the underline
(which is done before drawing the overline).  Otherwise the overline
would be drawn correctly, but underline won't.  If this is what you
had in mind, please go ahead and install the change in all the *term
backends.

Thanks.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> In w32term.c, I needed to place it before the drawing of the underline
> (which is done before drawing the overline).  Otherwise the overline
> would be drawn correctly, but underline won't.  If this is what you
> had in mind, please go ahead and install the change in all the *term
> backends.

Thanks, I'll do that.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> In w32term.c, I needed to place it before the drawing of the underline
>> (which is done before drawing the overline).  Otherwise the overline
>> would be drawn correctly, but underline won't.  If this is what you
>> had in mind, please go ahead and install the change in all the *term
>> backends.
>
> Thanks, I'll do that.

I've now installed the changes to the X and W32 port.  Protesilaos,
could you test and let us know if the problem has been resolved?

The NS port draws text decorations in an unconventional fashion, so it
will take some more time for me to make the change there.

Thanks.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 52324@debbugs.gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 12 Dec 2021 21:12:58 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> >> In w32term.c, I needed to place it before the drawing of the underline
> >> (which is done before drawing the overline).  Otherwise the overline
> >> would be drawn correctly, but underline won't.  If this is what you
> >> had in mind, please go ahead and install the change in all the *term
> >> backends.
> >
> > Thanks, I'll do that.
> 
> I've now installed the changes to the X and W32 port.

Thanks, the problem is fixed here on MS-Windows.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> The NS port draws text decorations in an unconventional fashion, so it
> will take some more time for me to make the change there.

It should now be fixed on the NS port as well.

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Protesilaos Stavrou]

On 2021-12-12, 21:12 +0800, Po Lu <luangruo@yahoo.com> wrote:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> In w32term.c, I needed to place it before the drawing of the underline
>>> (which is done before drawing the overline).  Otherwise the overline
>>> would be drawn correctly, but underline won't.  If this is what you
>>> had in mind, please go ahead and install the change in all the *term
>>> backends.
>>
>> Thanks, I'll do that.
>
> I've now installed the changes to the X and W32 port.  Protesilaos,
> could you test and let us know if the problem has been resolved?

Thanks!  I will test it tomorrow morning and report back to you.

-- 
Protesilaos Stavrou
https://protesilaos.com

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Protesilaos Stavrou]

On 2021-12-12, 21:12 +0800, Po Lu <luangruo@yahoo.com> wrote:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> In w32term.c, I needed to place it before the drawing of the underline
>>> (which is done before drawing the overline).  Otherwise the overline
>>> would be drawn correctly, but underline won't.  If this is what you
>>> had in mind, please go ahead and install the change in all the *term
>>> backends.
>>
>> Thanks, I'll do that.
>
> I've now installed the changes to the X and W32 port.  Protesilaos,
> could you test and let us know if the problem has been resolved?

Good day!

I can confirm that the following works on my end:

    (setq x-underline-at-descent-line t
          x-use-underline-position-properties nil)

    (set-face-attribute 'mode-line nil
                        :foreground "black"
                        :background "gray80"
                        :box '(:line-width 6 :color "gray80")
                        :overline "gray30"
                        :underline "gray30"
                        :distant-foreground 'unspecified)

M-x emacs-version:

    GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
    3.24.30, cairo version 1.17.4) of 2021-12-13.

-- 
Protesilaos Stavrou
https://protesilaos.com

bug#52324: 29.0.50; "Padded" mode line lacks uniform border

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Protesilaos Stavrou <info@protesilaos.com> writes:

> Good day!
>
> I can confirm that the following works on my end:
>
>     (setq x-underline-at-descent-line t
>           x-use-underline-position-properties nil)
>
>     (set-face-attribute 'mode-line nil
>                         :foreground "black"
>                         :background "gray80"
>                         :box '(:line-width 6 :color "gray80")
>                         :overline "gray30"
>                         :underline "gray30"
>                         :distant-foreground 'unspecified)
>
> M-x emacs-version:
>
>     GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>     3.24.30, cairo version 1.17.4) of 2021-12-13.

Fantastic, thanks for testing!  I'm closing the bug report.