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: martin rudalics <rudalics <at> gmx.at>, 73734 <at> debbugs.gnu.org
Subject: bug#73734: [PATCH] Fix tmm menu layout
Date: Thu, 10 Oct 2024 20:00:59 +0200
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 10 Oct 2024 15:53:12 +0200
>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Depending on the frame and font size, some tmm menus could be somewhat
>> hard to read.  Here is what I get with the "Mark" menu from a Dired
>> buffer:
>> 
>> The selection character could be mistaken for part of another
>> keybinding.
>
> 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.
[2024-10-10T15:25+0200.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
>> 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.

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

> Finally, does this change some user-facing aspect of the tmm behavior?
> If so, maybe we need a NEWS entry.

I don't think there is behavioral change only a layout change here.
-- 
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.