bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Garreau, Alexandre]

Given this (rectangular) excerpt from my bug-gnu-emacs summary:
> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…

On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
“]” sooner than the others.  This is because `gnus-correct-length'
(along with `char-width') says each of the first three characters is
two-columns wide: but under GUI, this is untrue, as these three
collectively form exactely 5 columns (and not six, as would calculate
`gnus-correct-length').

You can check that by eval’ing:
> (window-text-pixel-size nil (- (point) 593) (- (point) 588))
> (window-text-pixel-size nil (- (point) 583) (- (point) 580))
which return the width of the three first characters after “[” in the
two last summary lines.

According `gnus-correct-length' they’r the same size:
> (gnus-correct-length "[積丹尼 Dan Jacobson             ]")
> (gnus-correct-length "[-> Noam Postavsky               ]")

According `char-width' the fact each character is considered to have a
width which is a multiple of the others makes them the same size:
> (mapcar #'char-width "[積丹尼 Dan Jacobson             ]")
> (mapcar #'char-width "[-> Noam Postavsky               ]")

So would it be better to get gnus-correct-length keep returning a column
number but as a float to be somewhat compatible? or working with pixels
when operating in a GUI frame? but how would padding, which is said to
be in numbers of column, operate then?

or should it stay with a behavior that works in terminal but breaks in
gui?

I’m reporting this at least for archive, in case someone have an idea.
But I’m not sure the solution is that trivial.

Gnus v5.13
GNU Emacs 25.1.1 (i686-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-09-15, modified by Debian

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Eric Abrahamsen]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> Given this (rectangular) excerpt from my bug-gnu-emacs summary:
>> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
>> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
>> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
>> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…
>
> On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
> “]” sooner than the others.  This is because `gnus-correct-length'
> (along with `char-width') says each of the first three characters is
> two-columns wide: but under GUI, this is untrue, as these three
> collectively form exactely 5 columns (and not six, as would calculate
> `gnus-correct-length').

Someone just reported something similar on the org list, that
`string-width' doesn't return the actual width occupied by the string,
which you'd think would be the whole point.

(BTW, it looks like `gnus-correct-length' can be replaced by
`string-width'.)

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Noam Postavsky]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>
>> Given this (rectangular) excerpt from my bug-gnu-emacs summary:
>>> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
>>> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
>>> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
>>> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…
>>
>> On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
>> “]” sooner than the others.  This is because `gnus-correct-length'
>> (along with `char-width') says each of the first three characters is
>> two-columns wide: but under GUI, this is untrue, as these three
>> collectively form exactely 5 columns (and not six, as would calculate
>> `gnus-correct-length').
>
> Someone just reported something similar on the org list, that
> `string-width' doesn't return the actual width occupied by the string,
> which you'd think would be the whole point.

See Bug#31588, the width of these characters depends on the font, so
string-width (which works only on a string) can't give the right answer.
Or, from another point of view, it's the font's fault for being too
narrow on these characters.

> (BTW, it looks like `gnus-correct-length' can be replaced by
> `string-width'.)

Yep.

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Eric Abrahamsen]

On 11/01/18 19:26 PM, Noam Postavsky wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> "Garreau, Alexandre" <galex-713@galex-713.eu> writes:
>>
>>> Given this (rectangular) excerpt from my bug-gnu-emacs summary:
>>>> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
>>>> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
>>>> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
>>>> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…
>>>
>>> On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
>>> “]” sooner than the others.  This is because `gnus-correct-length'
>>> (along with `char-width') says each of the first three characters is
>>> two-columns wide: but under GUI, this is untrue, as these three
>>> collectively form exactely 5 columns (and not six, as would calculate
>>> `gnus-correct-length').
>>
>> Someone just reported something similar on the org list, that
>> `string-width' doesn't return the actual width occupied by the string,
>> which you'd think would be the whole point.
>
> See Bug#31588, the width of these characters depends on the font, so
> string-width (which works only on a string) can't give the right answer.
> Or, from another point of view, it's the font's fault for being too
> narrow on these characters.

Yeah, I figured it was probably a font issue, but still it's kind of
misleading to have a function that *sounds* like it's going to handle
the font issue, but doesn't.

>> (BTW, it looks like `gnus-correct-length' can be replaced by
>> `string-width'.)
>
> Yep.

Made a bug report.

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 01 Nov 2018 16:52:32 -0700
> Cc: 33232@debbugs.gnu.org
> 
> >>> Given this (rectangular) excerpt from my bug-gnu-emacs summary:
> >>>> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
> >>>> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
> >>>> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
> >>>> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…
> >>>
> >>> On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
> >>> “]” sooner than the others.  This is because `gnus-correct-length'
> >>> (along with `char-width') says each of the first three characters is
> >>> two-columns wide: but under GUI, this is untrue, as these three
> >>> collectively form exactely 5 columns (and not six, as would calculate
> >>> `gnus-correct-length').
> >>
> >> Someone just reported something similar on the org list, that
> >> `string-width' doesn't return the actual width occupied by the string,
> >> which you'd think would be the whole point.
> >
> > See Bug#31588, the width of these characters depends on the font, so
> > string-width (which works only on a string) can't give the right answer.
> > Or, from another point of view, it's the font's fault for being too
> > narrow on these characters.
> 
> Yeah, I figured it was probably a font issue, but still it's kind of
> misleading to have a function that *sounds* like it's going to handle
> the font issue, but doesn't.

The only reliable way of getting pixelwise alignment in GUI frames is
to use the :align-to display spec, or other related display property
specs that provide pixelwise width and alignment.

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 01 Nov 2018 15:52:14 -0700
> 
> Someone just reported something similar on the org list, that
> `string-width' doesn't return the actual width occupied by the string,
> which you'd think would be the whole point.

string-width does the best job it can, but you cannot hope to get
exact results when using variable-width fonts.  What string-width
returns should be correct on TTY frames, and only an approximation of
GUI frames, when you mix scripts and thus fonts in the same string.

For pixel-level accuracy on display, you must use display 'space' and
'align' properties.

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 01 Nov 2018 16:52:32 -0700
> Cc: 33232@debbugs.gnu.org
> 
> > See Bug#31588, the width of these characters depends on the font, so
> > string-width (which works only on a string) can't give the right answer.
> > Or, from another point of view, it's the font's fault for being too
> > narrow on these characters.
> 
> Yeah, I figured it was probably a font issue, but still it's kind of
> misleading to have a function that *sounds* like it's going to handle
> the font issue, but doesn't.

What part of "string-width" tells you that it handles fonts?

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 01 Nov 2018 16:52:32 -0700
>> Cc: 33232@debbugs.gnu.org
>> 
>> >>> Given this (rectangular) excerpt from my bug-gnu-emacs summary:
>> >>>> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
>> >>>> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
>> >>>> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
>> >>>> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…
>> >>>
>> >>> On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
>> >>> “]” sooner than the others.  This is because `gnus-correct-length'
>> >>> (along with `char-width') says each of the first three characters is
>> >>> two-columns wide: but under GUI, this is untrue, as these three
>> >>> collectively form exactely 5 columns (and not six, as would calculate
>> >>> `gnus-correct-length').
>> >>
>> >> Someone just reported something similar on the org list, that
>> >> `string-width' doesn't return the actual width occupied by the string,
>> >> which you'd think would be the whole point.
>> >
>> > See Bug#31588, the width of these characters depends on the font, so
>> > string-width (which works only on a string) can't give the right answer.
>> > Or, from another point of view, it's the font's fault for being too
>> > narrow on these characters.
>> 
>> Yeah, I figured it was probably a font issue, but still it's kind of
>> misleading to have a function that *sounds* like it's going to handle
>> the font issue, but doesn't.
>
> The only reliable way of getting pixelwise alignment in GUI frames is
> to use the :align-to display spec, or other related display property
> specs that provide pixelwise width and alignment.

Interesting, maybe that's something that Org tables should be using.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 01 Nov 2018 16:52:32 -0700
>> Cc: 33232@debbugs.gnu.org
>> 
>> > See Bug#31588, the width of these characters depends on the font, so
>> > string-width (which works only on a string) can't give the right answer.
>> > Or, from another point of view, it's the font's fault for being too
>> > narrow on these characters.
>> 
>> Yeah, I figured it was probably a font issue, but still it's kind of
>> misleading to have a function that *sounds* like it's going to handle
>> the font issue, but doesn't.
>
> What part of "string-width" tells you that it handles fonts?

No, I know that wasn't a reasonable expectation, but I think it's an
easy mistake to make.

bug#33232: `gnus-summary-line-format' padding doesn’t work in gui when there are multiple-column-width characters

[Lars Ingebrigtsen]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> Given this (rectangular) excerpt from my bug-gnu-emacs summary:
>> …01-nov…[-> 33224@debbugs.gnu.org        ] bug#33224: `message-simpli…
>> …01-nov…[Noam Postavsky                  ] bug#33225: [debbugs.el] Do…
>> …01-nov…[-> Noam Postavsky               ]  bug#33225: [debbugs.el] D…
>> …01-nov…[積丹尼 Dan Jacobson             ] bug#33226: chromium, firef…
>
> On my system (Debian, with Xorg, i3, GUI Emacs), the last line has its
> “]” sooner than the others.  This is because `gnus-correct-length'
> (along with `char-width') says each of the first three characters is
> two-columns wide: but under GUI, this is untrue, as these three
> collectively form exactely 5 columns (and not six, as would calculate
> `gnus-correct-length').

Yes, using characters from a mixture of fonts that have widths that do
not add up to multiples of each other just isn't supported by Gnus.  To
do so would require a rewrite of the machinery that generates the
buffers, and gnus-summary-line-format would have to be obsoleted and
something new that uses display properties with align-to could be used.

So I'm closing this bug report as a "wontfix".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no