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

Previous Next

Full log

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

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: Re: bug#73734: [PATCH] Fix tmm menu layout
Date: Fri, 11 Oct 2024 10:10:25 +0200

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

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.)

With the following patch:

[my.patch (text/x-patch, inline)]

diff --git a/lisp/tmm.el b/lisp/tmm.el
index 1e3942761a1..8d1f9b15e82 100644
--- a/lisp/tmm.el
+++ b/lisp/tmm.el
@@ -484,13 +484,12 @@ tmm-get-keymap
             (when binding
               (setq binding (key-description binding))
               ;; Try to align the keybindings.
-              (let ((colwidth (- (/ (frame-width) 3) 15)))
+              (let* ((colwidth (min 30 (- (/ (window-width) 2) 10)))
+                     (spaces (max 2 (- colwidth (string-width str)
+                                       (string-width binding)))))
                 (setq str
                       (concat str
-                              (make-string (max 2 (- colwidth
-                                                     (string-width str)
-                                                     (string-width binding)))
-                                           ?\s)
+                              (propertize " " 'display `(space . (:width ,spaces)))
                               binding)))))))
       (and km (stringp km) (setq str km))
       ;; Verify that the command is enabled;

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

The result is even worse because now there is wrapping involved:

[2024-10-11T10:06+0200.png (image/png, inline)]

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

-- 
Manuel Giraud

Previous Next

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