GNU bug report logs - #73734
[PATCH] Fix tmm menu layout

Previous Next

Package: emacs;

Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>

Date: Thu, 10 Oct 2024 13:54:01 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 73734 <at> debbugs.gnu.org
Subject: bug#73734: [PATCH] Fix tmm menu layout
Date: Fri, 11 Oct 2024 09:45:04 +0200
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.