bug#6755: 24.0.50; Customize buffer is too wide. Put doc string on separate line.

[Drew Adams]

> > 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: 

I disagree that it makes no sense.  In fact I think it
makes a lot of sense.  Hence this enhancement request.

> we would be artificially separating the value menu
> button from the description of the current value.

Look at the screenshots.  I don't see why anyone would
find it odd, let alone "make no sense") to show the doc
for the current value just below button, on the next line.

But there's no accounting for tastes, as they say.
You have yours; I have mine.

To me it's artificial to show the :tag text to the right
of the button, especially when it is more than a few
chars long.

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

That's what this enhancement request is about.  Does
that count as "insistence"?

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

Not the same at all.  Why? because Customize sticks
a variable amount of stuff before the :tag text.

1. You know where a doc string will be displayed,
   and it always starts in column 1.

2. But :tag text depends on the stuff that Customize
   adds to the buffer before it.

   In the case of the `Value Menu' button, that
   stuff includes the option (or face) name, which
   varies from option to option.

   That means that the longer the option name, the
   less room for the :tag string.  There should be
   no such relation between their lengths.  (Why
   would there be?)

   The :tag in the screenshot is 55 chars.  Given
   the option name of 34 chars, plus the colon,
   `Value Menu' button, and spaces Customize adds,
   there is only room for a :tag of 30 chars.

3. Imagine if we did something similar for `C-h v':
   Put, say, the first line of the doc string (or
   some other descriptive text, if you don't like
   that hypothetical) to the right of the var name.

   That wouldn't make much sense, would it?  Why?
   Because a long variable name would mean you'd
   have to use a short description.

   There's no reason to impose any relation between
   those lengths.  Doing so "makes no sense", to me.
 
> > 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.