GNU bug report logs -
#73734
[PATCH] Fix tmm menu layout
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: rudalics <at> gmx.at, 73734 <at> debbugs.gnu.org
>> Date: Fri, 11 Oct 2024 08:37:00 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Ah, I see now what you meant. But if this is the problem, then
>> > changing the column width is not a reliable solution, because you
>> > cannot know in advance what will be the width of the SPC glyph in a
>> > font people use. I suggest to use 'display' properties instead, for
>> > example '(space . (:width N)), where N is the number of canonical
>> > columns we want the space to take on display.
>>
>> Sure this will be more reliable for proportional font's users but we'll
>> still need to calculate this N that would be (- colwidth (string-width
>> str) (string-width binding)) I think. And so we still need a value for
>> colwidth, no?
>
> Yes, we will still need a value for colwidth. But string-width counts
> columns, so it returns the same value for fixed-pitch and
> variable-pitch fonts alike; it doesn't count pixels. Using 'display'
> properties, we can force the SPC characters used as delimiters to take
> exactly one canonical column, even if the font actually used has
> narrower glyphs for SPC. So the computed colwidth value will be
> displayed reliably, and will never cause the visual confusion which
> you show on your screenshot. In which case we can leave the
> currently-computed colwidth value alone, as it is not what causes the
> problem. (We could also decide to use other values for colwidth, but
> it would be a separate issue, unrelated to the confusing display.)
Ok. I'll try this and see for the result.
--
Manuel Giraud
This bug report was last modified 271 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.