Re: customize options and faces are not in alphabetical order
If the default sort order cannot be changed now, can the custom sort options at least be autoloaded? That would let users know that there is a workaround available. I did that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
Drew Adams wrote: 1. Reminder: The bug report was about the default order of options in a custom buffer. If it were alphabetical, users could find options there easier. I can't think of any other program that orders its options alphabetically by default. Usually they are grouped by functionality, and ordered by importance/usefulness. Ordering the options alphabetically only helps users who are looking for a specific option that they know the name of, but there are better ways of finding a specific option than browsing a whole group and scanning through. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
I do not want a discussion about redesigning the Custom interface now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
I do not want a discussion about redesigning the Custom interface now. Of course not. If the default sort order cannot be changed now, can the custom sort options at least be autoloaded? That would let users know that there is a workaround available. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
And how do you know what custom group to look in? These are options that are not autoloaded (so unavailable to C-h v and apropos) and are not mentioned in any manual. One way is to browse through the structure of custom groups. But it would be good if Custom buffers had some menu bar item leading to customizing the custom group for custom buffers. Would someone please add that? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
And how do you know what custom group to look in? These are options that are not autoloaded (so unavailable to C-h v and apropos) and are not mentioned in any manual. One way is to browse through the structure of custom groups. But it would be good if Custom buffers had some menu bar item leading to customizing the custom group for custom buffers. Would someone please add that? 1. Reminder: The bug report was about the default order of options in a custom buffer. If it were alphabetical, users could find options there easier. I don't see the utility of the current default order, which I mistook to be more or less random. The explanation I got was that this default order reflects the guideline to write options such that an option `bar' depending on an option `foo' appears in the customization buffer after `foo' unless the user deliberately changed that order. What is the reason for that guideline, and just what kind of dependency are we talking about here? What makes the default order a good one for users? 2. If the current default order is kept, is there a reason that the custom sort options shouldn't be autoloaded, so that users can find out about them through `C-h v' or `apropos'? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
- They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. How can `C-h v' help you to find something you're not aware of? That's not the point. The point is that these should be well documented, and autoloaded so you can get to the documentation. Many Emacs users don't care about customization. So? Bug reports about customization don't concern such users, so ignore them in the present context. If you don't care about customization either, then perhaps someone else should respond to this bug report. I do care about customization, and that's why I reported the bug. I would appreciate a lot if you tried to improve its documentation. I try to improve it by pointing out problems with it. FYI, GNU will not accept my patches, doc or code, because my employer will not sign papers. My contribution is bug reports and general suggestions - if they help, fine; if not, ignore. In this case, one needed improvement is to autoload (or equivalent) the defcustoms. However, C-h v can easily help you find something you are not aware of, by showing you what's available with completion. I do it every day. C-h v with completion is hardly an option for beginners and hardly useful when there are many completions. I disagree. Completion is a real aid for beginners, as well as for non-beginners. Apropos is another aid in this context. It is also rendered impotent if the variables have not been loaded or autoloaded. - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? They would browse customization groups, try options, and use them. OK, that's one way to find them. C-h v or apropos is another. That the former way is available as an alternative is no solution for the problem that the latter way is broken. - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? The nil order is the one chosen by the designer of the option. Emacs maintainers are now responsible. I don't know what the designer's rationale was, and I don't see a good rationale. I was asking if there is one. The designers of an option are the persons who invented the option, assigned a name to it, and wrote the customization definition. Their rationale should be to write options such that an option `bar' depending on an option `foo' appears in the customization buffer after `foo' unless the user deliberately changed that order. I see. I guess you're saying that that is the default order that I was calling random. I don't know if the guideline you just mentioned is documented for designers, but the resulting order is, IMO, not obvious or understandable to users - it might as well be random. In any case, the designer is out of the loop now, for this bug fix, unless a maintainer wants to contact the designer for some reason. I don't understand why we would even have such options - who would ever want a random order? Why do you think it's random? I said apparently. I have no idea what determines the order. It is not an obvious, understandable, or obviously useful order. I don't care if it's actually random. I asked if there was a good reason for it, and you essentially told me to go ask the designer. Indeed. You should tell the designers of the options for a specific group whenever you think they wrote them in an inappropriate way. This is a standard GNU-Emacs library. I don't know (or care) who the designers of these options is. I reported a bug; that's all. If a bug fixer wants to contact the designer to understand the original rationale, feel free. I'm just reporting a bug. As always, it's your prerogative to decide not to fix the bug or to decide that there is in fact no bug. I would think that bug reports would be welcomed, as an aid, instead of resisted, as if they were imposing unnecessary chores. This push-back is not helpful, IMO. I personally won't be discouraged, by your attitude, from reporting other bugs, but I expect that some others might be. Please don't adopt this attitude as a general response to bug reports, or we will lose lots of good input from users. A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag None nil) function)) I personally don't see why anyone would want an order other
Re: customize options and faces are not in alphabetical order
So? Bug reports about customization don't concern such users, so ignore them in the present context. If you don't care about customization either, then perhaps someone else should respond to this bug report. I do care about customization, and that's why I reported the bug. Sorry. I herewith apologize for answering to your bug report. Please disregard my comments on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
- None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. We do not aim to mention all options in the manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? If you want to change things about a certain feature (such as the custom buffer interface), you look at its custom group and see what's available. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? If you want to change things about a certain feature (such as the custom buffer interface), you look at its custom group and see what's available. And how do you know what custom group to look in? These are options that are not autoloaded (so unavailable to C-h v and apropos) and are not mentioned in any manual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
- None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. We do not aim to mention all options in the manual. Of course not, and these probably need not be in a manual. My point was that if they are not autoloaded and they are not mentioned in a manual, it's difficult to know they exist. Autoloading was my suggestion. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
emacs -Q M-x customize some-group The options and faces should be in alphabetical order. The actual order seems random. Should be possible: (defcustom custom-browse-sort-alphabetically nil If non-nil, sort members of each customization group alphabetically. :type 'boolean :group 'custom-browse) (defcustom custom-buffer-sort-alphabetically nil If non-nil, sort members of each customization group alphabetically. :type 'boolean :group 'custom-buffer) (defcustom custom-menu-sort-alphabetically nil If non-nil, sort members of each customization group alphabetically. :type 'boolean :group 'custom-menu) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
From: martin rudalics emacs -Q M-x customize some-group The options and faces should be in alphabetical order. The actual order seems random. Should be possible: (defcustom custom-browse-sort-alphabetically nil If non-nil, sort members of each customization group alphabetically. :type 'boolean :group 'custom-browse) (defcustom custom-buffer-sort-alphabetically nil If non-nil, sort members of each customization group alphabetically. :type 'boolean :group 'custom-buffer) (defcustom custom-menu-sort-alphabetically nil If non-nil, sort members of each customization group alphabetically. :type 'boolean :group 'custom-menu) Thx - I wasn't aware of those. However: - They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. - What is the difference between them, besides the fact that they are in different subgroups of the Customize group? They have identical doc strings - how is a user to understand their difference? What is the scope of the sorting (where are the members sorted)? Why are there 3 separate options for this, if they all do the same thing (same doc string)? - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? I don't understand why we would even have such options - who would ever want a random order? A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag None nil) function)) I personally don't see why anyone would want an order other than alphabetic, but at least that would be a reasonable way to give people a choice. The current approach does not seem useful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
Thx - I wasn't aware of those. However: - They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. How can `C-h v' help you to find something you're not aware of? - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. - What is the difference between them, besides the fact that they are in different subgroups of the Customize group? They have identical doc strings - how is a user to understand their difference? What is the scope of the sorting (where are the members sorted)? Why are there 3 separate options for this, if they all do the same thing (same doc string)? This should be improved. - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? The nil order is the one chosen by the designer of the option. I don't understand why we would even have such options - who would ever want a random order? Why do you think it's random? A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag None nil) function)) I personally don't see why anyone would want an order other than alphabetic, but at least that would be a reasonable way to give people a choice. The current approach does not seem useful. It would give people the inverse choice, not fundamentally different though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
- They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. How can `C-h v' help you to find something you're not aware of? That's not the point. The point is that these should be well documented, and autoloaded so you can get to the documentation. However, C-h v can easily help you find something you are not aware of, by showing you what's available with completion. I do it every day. - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? - What is the difference between them, besides the fact that they are in different subgroups of the Customize group? They have identical doc strings - how is a user to understand their difference? What is the scope of the sorting (where are the members sorted)? Why are there 3 separate options for this, if they all do the same thing (same doc string)? This should be improved. Agreed. - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? The nil order is the one chosen by the designer of the option. Emacs maintainers are now responsible. I don't know what the designer's rationale was, and I don't see a good rationale. I was asking if there is one. I don't understand why we would even have such options - who would ever want a random order? Why do you think it's random? I said apparently. I have no idea what determines the order. It is not an obvious, understandable, or obviously useful order. I don't care if it's actually random. I asked if there was a good reason for it, and you essentially told me to go ask the designer. A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag None nil) function)) I personally don't see why anyone would want an order other than alphabetic, but at least that would be a reasonable way to give people a choice. The current approach does not seem useful. It would give people the inverse choice, not fundamentally different though. Fundamentally different: they could supply any sort function. Now they have a choice between string-lessp and nil, that's all. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
