emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: customize options and faces are not in alphabetical order


From: martin rudalics
Subject: Re: customize options and faces are not in alphabetical order
Date: Sat, 23 Dec 2006 00:35:17 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]