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

Previous Next

Full log

Message #8 received at 75020 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75020 <at> debbugs.gnu.org
Subject: Re: bug#75020: [PATCH] Fix make-separator-line for ttys not supporting
 underline
Date: Sun, 22 Dec 2024 10:22:02 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.