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


Message #17 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 08:37:00 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: martin rudalics <rudalics <at> gmx.at>,  73734 <at> debbugs.gnu.org
>> Date: Thu, 10 Oct 2024 20:00:59 +0200
>> 
>> > What is the "selection character" in this image?
>> 
>> On the image below, "n" is what I called the selection character for
>> "Next Marked" while "* c" is the keybinding for "Change Marks...".  The
>> proximity of those two makes this hard to read IMO.
>
> 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?

[...]

>> >> Here, how I justify the modification of `colwidth':
>> >> 
>> >>       - I don't think we need the "(min 30)" part since, if the frame is
>> >>         wide enough, we always get a colwidth of 30.
>> >>         
>> >>       - I don't think "(window-width)" is what we need since, by
>> >>         default, the *Completions* buffer will use the full frame width.
>> >
>> > Martin, is that guaranteed?
>> >
>> > And even if it is, what's the harm in keeping window-width?
>> 
>> I don't think that a full frame width *Completions* buffer is
>> guaranteed: it is only what I see with "emacs -Q".
>> 
>> Keeping window-width in this calculation seems a bit strange because, by
>> default, it has nothing to do with the *Completions* buffer window
>> width.
>
> Which window's width does this return in this case?

AFAIU, this window-width call is done from the user's current window.
-- 
Manuel Giraud




This bug report was last modified 270 days ago.

Previous Next


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