Re: Value menu value should be listed on a separate line
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
RE: Value menu value should be listed on a separate line
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: ...xxx [Value Menu] the-value then consider this: ...xxx [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
Re: Value menu value should be listed on a separate line
When a value menu is present, the current value should be on a separate line from the Value Menu button. Currently, the current value is listed next to the Value Menu button, which makes the Customize buffer far too wide. The author of an option is responsible for its appearance. Tags for menu items are generally less than 81 characters wide. Putting the value (tag) on a separate line would mean that the entire buffer would generally be no more than 80 chars wide. Currently, a buffer with a 70-char value has a width of about 134. This should be decided for each option individually. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
When a value menu is present, the current value should be on a separate line from the Value Menu button. Currently, the current value is listed next to the Value Menu button, which makes the Customize buffer far too wide. The author of an option is responsible for its appearance. Uh, how is the author supposed to start a value that has a tag on a separate line? Usually with :entry-format and :format. 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Value menu value should be listed on a separate line
When a value menu is present, the current value should be on a separate line from the Value Menu button. Currently, the current value is listed next to the Value Menu button, which makes the Customize buffer far too wide. The author of an option is responsible for its appearance. Uh, how is the author supposed to start a value that has a tag on a separate line? 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. 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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
