[Top][All Lists]

[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 10:47:26 +0100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

>> > - 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.  I would appreciate a
lot if you tried to improve its 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.

C-h v with completion is hardly an option for beginners and hardly
useful when there are many completions.

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

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

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

reply via email to

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