RE: Value menu value should be listed on a separate line

[Drew Adams]

>  >>Usually with ":entry-format" and ":format".
>  >
>  > No special formatting should be necessary, just to be able to
>  > use a simple tag. I don't believe that was why :*format were
>  > introduced.
>
> You would have to specify what a "simple" tag is in the first place.

I would? My bug report was clear enough, I think, for someone who really
wants to understand.

I did give a concrete example, however: a literal string of less than 80
characters.

> Formatting tags is for handling non-standard cases like, for example,
> options whose values may be variable-length strings.  Such options are
> not necessarily preceded by a [Value Menu].

Then why do you bring them up? The bug report is about option values that
are preceded by [Value Menu], and it doesn't mention formatting tags - you
brought that up. The examples I gave were not variable-length strings. Why
introduce a distraction unrelated to the reported problem? No formatting
should be necessary for the simple cases reported.

>  >> > Writers of defcustom's shouldn't need to concern themselves
>  >> > with the layout
>  >> > of the Customize buffer, anyway. They should be able to define
>  >> > a :tag string
>  >> > without the preoccupation of its starting position and the number of
>  >> > characters already taken up by the option name and the
>  >> > button widths.
>  >>
>  >>I'm convinced that writers of defcustoms should care about the layout.
>  >
>  > OK, you're convinced. I said that they should not *need* to concern
>  > themselves with the layout of stuff, beyond their own
>  > creations. This is a flaw in the basic layout, which should not be
>  > shoved off onto the definers of individual values, to work around.
>  > It should be trivial to fix, no less - why not fix the general case,
>  > instead of making writers of each value work around it over and over?
>
> Your general case is based on the presence of the term [Value Menu].
> Often that term is followed by a fixed-length string

That's exactly the case I reported: [Value Menu] followed by a
(fixed-length) :tag string.

> or an integer as in the following excerpt from the comment group:

[snip]

> Moving the text after [Value Menu] to a new line would render this
> customization buffer completely unreadable.

I disagree. There is no reason that the value should follow [Value Menu] on
the same line. What compelling reason is there? How does that enhance
readability?

If, however, you are convinced that they must remain together, then consider
starting [Value Menu] and the value together on a new line. That is, if you
don't like this:

 xxxxxxxx...xxxxxxxxxxx [Value Menu]
 the-value

then consider this:

 xxxxxxxx...xxxxxxxxxxx
 [Value Menu] the-value

I see no reason why [Value Menu] needs to be next to the value, nor why
either needs to be at the end of a possibly long line of stuff (option name,
buttons).

It makes sense to always start the value in column 1, especially since 1)
values can be of any length and 2) a very common case is the use of a :tag,
which provides a string value, in a `choice'. That is the case I reported.

> Hence, I'm against a trivial fix.

I think you are against any fix at all. The ball is in your hands; if you
don't want to fix it, then you won't fix it. I've done my reporting job;
it's your turn.