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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@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!