GNU bug report logs - #75020
[PATCH] Fix make-separator-line for ttys not supporting underline

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sun, 22 Dec 2024 07:44:01 UTC

Severity: normal

Tags: patch

Fixed in version 31.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75020 <at> debbugs.gnu.org
Subject: Re: bug#75020: [PATCH] Fix make-separator-line for ttys not
 supporting underline
Date: Sun, 22 Dec 2024 14:19:31 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 75020 <at> debbugs.gnu.org
>> Date: Sun, 22 Dec 2024 09:49:34 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Thanks.  But I'm not sure this is for make-separator-line to decide.
>> > For example, after applying the patch, using this recipe:
>> >
>> >   M-: (insert (make-separator-line)) RET
>> >   M-x display-line-number-mode RET
>> >
>> > we will again get a too-long separator line.  And with this recipe:
>> >
>> >   M-x display-line-number-mode RET
>> >   M-: (insert (make-separator-line)) RET
>> >   M-x display-line-number-mode RET
>> >
>> > we will get a too-short separator line.
>> >
>> > So arguably, in these special cases, the caller should pass the
>> > required length as the optional argument, because only the caller
>> > knows the context in which the function is called and the purpose for
>> > which the separator will be used.  Which would mean the default of
>> > using window-width is correct.
>> >
>> > Does this make sense?
>> 
>> Yes, makes sense.
>> 
>> I noticed this too now with C-h f context-menu-mode, for example.
>> If the separator line size depends on the window which it currently
>> does, one gets different results.
>> 
>> And when the help buffer is shown in a different window, and in my case
>> to the left or right, it's almost always too long and wraps to 2 or 3
>> lines. It looks pretty weird.
>
> So I think we need to have bug reports for those applications where
> this happens, in particular in C-h.  That's where this should be
> fixed.

Actually, something else was also going on: bug#75024. Now I don't
have a terminal anymore where the dashes are used.




This bug report was last modified 201 days ago.

Previous Next


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