[Top][All Lists]

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

RE: `set-variable' should use :set

From: Drew Adams
Subject: RE: `set-variable' should use :set
Date: Fri, 22 Oct 2010 09:03:30 -0700

> I think Drew wants set-variable and customize-set-variable
> to be made more similar.  I would agree and I think we should
> merge them.  I would also suggest that it's a good opportunity
> to obsolete variable-interactive.

Yes, that all sounds good to me.

But the last part would hopefully entail automatically getting the equivalent of
`variable-interactive' from the custom type (e.g. along the lines I suggested).

And hopefully the type-checking would give you a better error message than the
generic "Value does not match number type".

And there is potential synergy between those two.
If, for example the :type is:

  :key-type (string :tag "Sort order")
  :value-type (choice :tag "Type"
               (const    :tag "None (do not sort)" nil)
               (function :tag "Sorting predicate")
               (list     :tag "Sorting multi-predicate"
                (repeat (function :tag "Component pred"))
                (choice :tag "Final predicate?"
                 (const    :tag "None" nil)
                 (function :tag "Predicate")))))

Then the interactive spec could allow completion or other appropriate input
methods (e.g. reading a number) for each of the parts in turn, type-checking it
individually.  If tags are present they could be used in the prompts.  Example:

1. "Sort order: "      no completion (string)

2. "Type: "            completion with candidates:
                        `None (do not sort)'
                        `Sorting predicate'
                        `Sorting multi-predicate'

3. Supposing `Sorting multi-predicate' was chosen:

   "Component pred: "  lax completion on fboundp symbols
   "Component pred: "  ... until empty input (for example)
4. "Final predicate? " completion with candidates:
                        `None', `Predicate'

5. Supposing `Predicate' was chosen:

   "Predicate: "       lax completion on fboundp symbols

If a tag is not provided, then the immediate type name would be used in its
place - e.g. "function: " if there were no tag "Sorting predicate".

This could go a long way toward helping, including dealing with typing mistakes
(in both senses of the word).  Currently, you're on your own coming up with a
proper Lisp sexp that fits the custom type - e.g. (("My Sort 1" (info-cp gnus-cp
file-cp) alpha-p)).  Currently the prompt just punts: "[alist] Set customized
value for ___ to: ".

Yes, use of such a `(customize-)set-variable' command would obviously be better
for simple custom types than for complex ones like this.  If the type is quite
complex then it can be easier/clearer to enter Customize and deal with it there.

The example is meant to show that _even_ complex types could be handled in a
relatively straightforward way.  Users might well prefer to enter Customize for
such a type rather than answer a series of voice-mail-hell-like prompts.  But
for simpler types avoiding Customize would be a worthwhile.

Essentially, the idea is that `(customize-)set-variable' would offer a (helpful)
minibuffer UI as an alternative to entering Customize in order change an option

The point is that we could do better than just prompt for a complete "[alist] "
value in one shot.  We could offer a reasonable way to input each of the value
components, providing completion as appropriate.  Each part would be
type-checked on its own, letting users know just where they go wrong when

And for times when you really want to input a fancy sexp and you prefer using
such a command to using setq (so you get type-checking), we could let `C-u' give
you the all-or-nothing "[alist] " prompt offered today.

reply via email to

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