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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75020 in the body.
You can then email your comments to 75020 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Fix make-separator-line for ttys not supporting underline
Date: Sun, 22 Dec 2024 08:43:14 +0100

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

Tags: patch

To reproduce, emacs -nw -Q on a terminal not supporting underlining (in
my case Terminal.app on macOS).

- M-x display-line-number-mode RET
- Eval (insert (amke-separator-line))

=> the separator line is too long

Attached patch fixes that.



In GNU Emacs 31.0.50 (build 4, aarch64-apple-darwin24.2.0) of 2024-12-21
 built on pro2
Repository revision: cbafbb2dd57993397c0d624461e3611831414e91
Repository branch: cl-packages
System Description:  macOS 15.2

Configured using:
 'configure --without-ns --cache-file
 /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.cl-packages
 --with-native-compilation --with-mps=yes CC=clang
 'CFLAGS=-Wgnu-imaginary-constant -Wunused-result -g
 -fno-omit-frame-pointer -F
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
 -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-type
 -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability
 -Wno-nullability-completeness' --prefix=/Users/gerd/.local'

[0001-Fix-make-separator-line-for-ttys-not-supporting-unde.patch (text/patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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 10:22:02 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Sun, 22 Dec 2024 08:43:14 +0100
> 
> To reproduce, emacs -nw -Q on a terminal not supporting underlining (in
> my case Terminal.app on macOS).
> 
> - M-x display-line-number-mode RET
> - Eval (insert (amke-separator-line))
> 
> => the separator line is too long
> 
> Attached patch fixes that.

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?

Message #11 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 09:49:34 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Sun, 22 Dec 2024 08:43:14 +0100
>> 
>> To reproduce, emacs -nw -Q on a terminal not supporting underlining (in
>> my case Terminal.app on macOS).
>> 
>> - M-x display-line-number-mode RET
>> - Eval (insert (amke-separator-line))
>> 
>> => the separator line is too long
>> 
>> Attached patch fixes that.
>
> 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.

But whatever, I'll close the bug in a minute. Thanks!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
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:20:16 +0200

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

> But whatever, I'll close the bug in a minute. Thanks!

Thanks.

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.

Previous Next

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