> >>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. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug