[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: customize-set-(value|variable) [was: apropos commands for commands,
From: |
Drew Adams |
Subject: |
RE: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables] |
Date: |
Sun, 11 Nov 2007 13:11:28 -0800 |
Resending.
The basic idea is to (1) let Customize use completion where possible and (2)
improve completion possibilities for `customize-set-value' and
`customize-set-variable'.
> From: Drew Adams Sent: Tuesday, November 06, 2007 2:46 PM
>
> Here are some proposals for discussion:
>
> 1. Rename `customize-set-value' to `set-option', and
> `customize-set-variable' to `set-option-default' (or
> add aliases). Users will find these names easier.
> These commands provide much better interaction
> for reading the new value than does the current
> `set-variable'. Their interaction subsumes that of
> `set-variable', which uses only property
> `variable-interactive'.
>
> 2. Rewrite `set-variable' to set any variable, not just an
> option, and when the variable is an option then have
> the code do what `customize-set-value' does. That is,
> provide better value input interaction, when possible.
>
> 3. `customize-set-(value|variable)' needs some improvement.
> Here are some things I notice:
>
> a. `choice' for a list of `const' is good - it provides
> completion, which is very handy - a great improvement
> over what is available in Customize, IMO. However,
> there is no indication in the prompt that completion
> is (sometimes) available. And when completion is
> available, the default value should be the current
> value of the option, for possible editing. Currently,
> there is no default value.
>
> b. `choice' that includes a non-`const' choice, in
> addition to `const' choices: the types of the
> non-`const' choices apparently govern what happens:
>
> - If the non-`const' choice types don't provide for
> completion, then no completion is available for the
> `choice' at all. It would be better to have non-strict
> completion and allow for the value that doesn't match
> any `const' to be read according to its type. If possible.
>
> - And, if the non-`const' choices also provide for
> completion, then it should be possible to combine them
> with the `const' values into a general completion. E.g.
> a `choice' of a `function' or (const :tag "None" nil)
> currently completes only against function names -
> neither "None" nor nil are allowed as completion
> candidates. Why not just add "None" to the list of
> candidates?
>
> c. `repeat' seems to read a sexp and evaluate to obtain
> the complete list - the complete value. This is a
> cop-out and is not very useful. It would be better to
> repeatedly read values corresponding to the list
> elements, and then combine them to get the overall
> value. For example `repeat' of `sexp' should
> repeatedly read a sexp (until, say, empty RET) and
> return the list of sexprs that were read. And I don't
> see why the command should `eval' at all for `repeat'
> - why wouldn't it just read, like it does for the
> other types? And the user has no feedback as to what
> is expected to be input (beyond "[repeat]" in the
> prompt) - nothing tells him to input a sexp that will
> be evalled to produce the overall list value. (And
> end users should not need to think in such terms, anyway.)
>
> c. (choice (const :tag "None" nil) regexp) reads a
> regexp string, but the default is "", not nil, which
> doesn't seem right. And if you type `nil' or `None',
> then the literal string "nil" or "None" is interpreted
> as a regexp. Again, it would be better to allow lax
> completion with sole candidate "None" and allow a
> regexp string value as well.
>
> d. For type `color', lax completion should be available,
> choosing from color names but also allowing input of a
> #RRRGGBBB hex string.
>
> #3 is the most important of these suggestions. I don't
> have time to work on this much myself, but I can
> contribute a little time if someone else lead on this.
> What's really needed is someone knowledgeable in custom
> and widgets (ugh!).
>
> I hope that people will not argue that users should not
> use `customize-set-value' and `customize-set-variable',
> that they should preferably use Customize. I think both
> have their advantages, and these commands should be
> improved to make them viable alternatives. I also think
> that Customize itself could be improved to allow for
> completion where appropriate.
>
> WDOT?
- customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables], Drew Adams, 2007/11/06
- RE: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables],
Drew Adams <=
- Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables], Lennart Borgman (gmail), 2007/11/11
- RE: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables], Drew Adams, 2007/11/11
- Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables], Lennart Borgman (gmail), 2007/11/11
- Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables], Richard Stallman, 2007/11/12
- Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables], Robert J. Chassell, 2007/11/12
- RE: customize-set-(value|variable) [was: apropos commands forcommands, user options, all functions, all variables], Drew Adams, 2007/11/12
- Re: customize-set-(value|variable) [was: apropos commands forcommands, user options, all functions, all variables], Robert J. Chassell, 2007/11/12
- RE: customize-set-(value|variable) [was: apropos commandsforcommands, user options, all functions, all variables], Drew Adams, 2007/11/12
- Re: customize-set-(value|variable) [was: apropos commandsforcommands, user options, all functions, all variables], Robert J. Chassell, 2007/11/12