bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]