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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: 75020@debbugs.gnu.org
>> Date: Sun, 22 Dec 2024 09:49:34 +0100
>> 
>> Eli Zaretskii <eliz@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.