GNU bug report logs - #52324
29.0.50; "Padded" mode line lacks uniform border

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52324 in the body.
You can then email your comments to 52324 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; "Padded" mode line lacks uniform border
Date: Mon, 06 Dec 2021 10:58:02 +0200

[Message part 1 (text/plain, inline)]

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

[emacs-27-mode-line-padded.png (image/png, attachment)]

[emacs-29-mode-line-padded.png (image/png, attachment)]

[emacs-29-mode-line-padded-mouse-pointer-button.png (image/png, attachment)]

Message #8 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: 52324 <at> debbugs.gnu.org
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Mon, 06 Dec 2021 16:47:17 +0200

> From: Protesilaos Stavrou <info <at> 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.

Message #11 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52324 <at> debbugs.gnu.org
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Mon, 06 Dec 2021 19:13:32 +0200

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

>> From: Protesilaos Stavrou <info <at> 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

Message #14 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 52324 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sat, 11 Dec 2021 15:47:24 +0200

> Date: Mon, 06 Dec 2021 16:47:17 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 52324 <at> debbugs.gnu.org
> 
> > From: Protesilaos Stavrou <info <at> 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.

Message #17 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52324 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 08:58:32 +0800

Eli Zaretskii <eliz <at> 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.

Message #20 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52324 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 10:48:35 +0800

Po Lu <luangruo <at> 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.

Message #23 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 52324 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 14:26:19 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: info <at> protesilaos.com,  52324 <at> 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.

Message #26 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 52324 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 21:03:45 +0800

Eli Zaretskii <eliz <at> 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.

Message #29 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: info <at> protesilaos.com
Cc: 52324 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 21:12:58 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Eli Zaretskii <eliz <at> 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.

Message #32 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: info <at> protesilaos.com
Cc: 52324 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 21:37:36 +0800

Po Lu <luangruo <at> 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.

Message #35 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 52324 <at> debbugs.gnu.org, info <at> protesilaos.com
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Sun, 12 Dec 2021 15:32:19 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 52324 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Sun, 12 Dec 2021 21:12:58 +0800
> 
> Po Lu <luangruo <at> 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.

Message #38 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 52324 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Mon, 13 Dec 2021 00:20:08 +0200

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

> Po Lu <luangruo <at> yahoo.com> writes:
>
>> Eli Zaretskii <eliz <at> 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

Message #41 received at 52324 <at> debbugs.gnu.org (full text, mbox):

From: Protesilaos Stavrou <info <at> protesilaos.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 52324 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Mon, 13 Dec 2021 08:54:50 +0200

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

> Po Lu <luangruo <at> yahoo.com> writes:
>
>> Eli Zaretskii <eliz <at> 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

Message #46 received at 52324-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Protesilaos Stavrou <info <at> protesilaos.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 52324-done <at> debbugs.gnu.org
Subject: Re: bug#52324: 29.0.50; "Padded" mode line lacks uniform border
Date: Mon, 13 Dec 2021 15:00:14 +0800

Protesilaos Stavrou <info <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.