GNU bug report logs - #6755
24.0.50; Customize buffer is too wide. Put doc string on separate line.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: larsi <at> gnus.org, maurooaranda <at> gmail.com, 6755 <at> debbugs.gnu.org
Subject: bug#6755: 24.0.50; Customize buffer is too wide. Put doc string on separate line.
Date: Sun, 22 Sep 2019 19:57:25 +0300

> Date: Sun, 22 Sep 2019 09:09:52 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: maurooaranda <at> gmail.com, larsi <at> gnus.org, 6755 <at> debbugs.gnu.org
> 
> It's about :tag lines.  The screenshots and the
> defcustom provided make that clear, I believe.
> 
> > Therefore, it makes no sense at all to start that text on a new line.
> 
> Why do you think that follows logically?  I don't.
> 
> This bug report / enhancement request is precisely to
> put that text on its own line.

And that's exactly what makes no sense: we would be artificially
separating the value menu button from the description of the current
value.

So if you insist on doing this, I object to this proposal.

> At least do so when the text would go past the conventional limit
> (70 chars or whatever) when placed after Customize constructs
> (boilerplate text, buttons, etc.).

No.  It is up to the Lisp programmers to make sure the text is short
enough to not cause this.  Exactly like with doc strings.

> > I also don't see how filling of any kind can make the situation better
> > when the textual description is too long.
> 
> This bug report does not ask for text filling, at all.
> Please move consideration/discussion of filling to
> a new bug report, if you're interested in that.

I only mentioned filling because that was one of the proposed
solutions.  We should NOT do any filling here.

> The problem is :tag lines.  They should be moved to
> their own line - at least when combining them with
> widget artifacts makes the resulting displayed content
> too wide.

Disagree.

Previous Next

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