RE: customize options and faces are not in alphabetical order

[Drew Adams]

>  >> > - 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
>  >> > 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.
>
> People already have the choice between using the order proposed by the
> designer and alphabetic order.  My remark applied to you proposal to
> invert the default value.

Yes, they have only that choice with the current code. (By "Now", I meant
with the current code, not with the code I suggested.) My response to you
was that with a function value they could have any order they liked; they
would not be limited to those two orders.

Again, I think that alphabetical order is all that is needed, but if you
want to give users a choice, then 1) make alphabetical the default sort and
2) make the variable value be a sort function, for generality.