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: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: rudalics <at> gmx.at, 73734 <at> debbugs.gnu.org
Subject: bug#73734: [PATCH] Fix tmm menu layout
Date: Thu, 10 Oct 2024 21:29:48 +0300
> 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.

> >> This patch tries to solves this issue.
> >
> > Can you tell how?  All I see is a different value for colwidth.  I
> > guess I'm missing something.
> 
> Yes but this different colwidth would leave more space between a
> keybinding and the "selection character" of the next column.  But, I
> have to say that it would be hard to prove that it will work for every
> possible settings.

Yes, I think using the 'display' property will be more reliable.

> >> 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?




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.