unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@Oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: "'Stephen J. Turnbull'" <stephen@xemacs.org>,
	'Miles Bader' <miles@gnu.org>,
	'Emacs-Devel devel' <emacs-devel@gnu.org>
Subject: RE: `set-variable' should use :set
Date: Fri, 22 Oct 2010 09:03:30 -0700	[thread overview]
Message-ID: <9D3797AD2E4848CB8459CA74A2218F63@us.oracle.com> (raw)
In-Reply-To: <jwv7hhaqqhq.fsf-monnier+emacs@gnu.org>

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

(alist
  :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
value.

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

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	other threads:[~2010-10-22 16:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 17:25 `set-variable' should use :set Drew Adams
2010-10-22  0:34 ` Miles Bader
2010-10-22  0:48   ` Miles Bader
2010-10-22  1:11     ` Drew Adams
2010-10-22  2:20       ` Stephen J. Turnbull
2010-10-22  4:34         ` Drew Adams
2010-10-22  7:17           ` Stephen J. Turnbull
2010-10-22  8:29             ` David Kastrup
2010-10-22 10:43           ` Juanma Barranquero
2010-10-22 13:40             ` Drew Adams
2010-10-22 14:02               ` David Kastrup
2010-10-22 22:42               ` Juanma Barranquero
2010-10-23  4:48                 ` Stephen J. Turnbull
2010-10-23 16:13                   ` Drew Adams
2010-10-23 17:47                     ` Juanma Barranquero
2010-10-23 18:44                       ` Glenn Morris
2010-10-23 19:01                       ` Jambunathan K
2010-10-24 16:15                       ` Chong Yidong
2010-10-22 14:01           ` Stefan Monnier
2010-10-22 16:03             ` Drew Adams [this message]
2010-10-22  7:42         ` Eli Zaretskii
2010-10-22  7:39       ` Eli Zaretskii
2010-10-22  8:16         ` Stephen J. Turnbull
2010-10-22  9:46           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9D3797AD2E4848CB8459CA74A2218F63@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).