[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#75020: [PATCH] Fix make-separator-line for ttys not supporting under
From: |
Gerd Möllmann |
Subject: |
bug#75020: [PATCH] Fix make-separator-line for ttys not supporting underline |
Date: |
Sun, 22 Dec 2024 09:49:34 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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!