>>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. 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]. >> > 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 or an integer as in the following excerpt from the comment group: ... comment-empty-lines: Hide Value Value Menu Never State: STANDARD. If nil, `comment-region' does not comment out empty lines. More comment-fill-column: Hide Value Value Menu nil State: STANDARD. Column to use for `comment-indent'. If nil, use `fill-column' instead. comment-padding: Hide Value Value Menu Integer: 1 State: SAVED and set. Padding string that `comment-region' puts between comment chars and text. More comment-style: Hide Value Value Menu plain ... Moving the text after [Value Menu] to a new line would render this customization buffer completely unreadable. Hence, I'm against a trivial fix. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug