[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: |
Eli Zaretskii |
Subject: |
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@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.
> But whatever, I'll close the bug in a minute. Thanks!
Thanks.