bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt

bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt

[Drew Adams]

Enhancement request:
 
Customize :type `restricted-sexp' is the most general composite type
construct.  As a result, programmers often use :tag to give some
indication to users what kind of Lisp sexp is acceptable.
 
But even if :tag is used, the prompt for the sexp is hard-coded as "Lisp
expression: ".  This makes little sense.  It makes more sense for the
:tag string to be used also as the prompt string.
 
At the least, this should be an option.
 
The prompt is too general.  Users customizing a particular
`restricted-sexp' are not necessarily even thinking that they are
entering a Lisp sexp, especially since the sexp is only read and not
evaluated.  The interface should be able to keep them thinking in terms
of the forms that are acceptable, i.e., the particular kind of Lisp
sexp.
 
Here is an example, where the sexp can be a character class.  The user
should think in terms of a character class, not just a "Lisp
expression".
 
(restricted-sexp :tag "Character class (e.g., [:space:])"
 :match-alternatives
 ((lambda (xx)
    (let (name)
      (and (vectorp xx)
           (= 1 (length xx))
           (symbolp (setq name  (aref xx 0)))
           (setq name  (symbol-name name))
           (eq ?: (aref name 0))
           (eq ?: (aref name (1- (length name)))))))))
 

In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> (restricted-sexp :tag "Character class (e.g., [:space:])"

That's not a sexp.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt

[Drew Adams]

The behavior I described is no doubt not what is seen with emacs -Q.

In emacs -Q the sexp is not read in the minibuffer.  In my setup it is.  I'm not
sure why, but if there is no case with vanilla Emacs where the sexp is read in
the minibuffer then this request can be closed.

In the example I was using for testing, the :type was actually a `choice', only
one choice of which was the `restrictive-sexp' as presented.

In my setup, when I choose that choice in Value Menu the sexp is read in the
minibuffer.  After it is read, the editable field has been created and populated
with the sexp read.  And thereafter `read' uses that field for the sexp.  IOW,
the field is not there at first, and the first `read' reads from the minibuffer.
Perhaps this behavior has something to do with my using a standalone minibuffer
frame - dunno.

In emacs -Q, when I choose that choice in Value Menu the editable field is
displayed immediately and the sexp is then read from there.

I don't know what causes this difference.

Here is a backtrace from my setup showing the call to `read'.  The prompt
appears when `minibuffer-depth-setup' is called (just before, presumably).

Debugger entered--entering a function:
* minibuffer-depth()
* minibuffer-depth-setup()
* #<subr read>(nil)
* apply(#<subr read> nil)
  read(nil)
* #[514 "\300\x01!\207" [read] 4 "\n\n(fn WIDGET VALUE)"]((restricted-sexp :tag
"Character class (e.g., [:space:])" :match-alternatives ((lambda (xx) (let
(name) (and (vectorp xx) (= 1 (length xx)) (symbolp (setq name (aref xx 0)))
(setq name (symbol-name name)) (eq 58 (aref name 0)) (eq 58 (aref name (1-
...))))))) :value nil) nil)
  widget-apply((restricted-sexp :tag "Character class (e.g., [:space:])"
:match-alternatives ((lambda (xx) (let (name) (and (vectorp xx) (= 1 (length
xx)) (symbolp (setq name (aref xx 0))) (setq name (symbol-name name)) (eq 58
(aref name 0)) (eq 58 (aref name (1- ...))))))) :value nil) :value-to-external
nil)
  widget-default-get((restricted-sexp :tag "Character class (e.g., [:space:])"
:match-alternatives ((lambda (xx) (let (name) (and (vectorp xx) (= 1 (length
xx)) (symbolp (setq name (aref xx 0))) (setq name (symbol-name name)) (eq 58
(aref name 0)) (eq 58 (aref name (1- ...))))))) :value nil))
  widget-choice-action((choice :args ((character :value "

I do not see where this is done by my code, but if it is, then this can be
closed.  It's not clear to me what is invoking `read' in this way, so that it
reads a sexp from the minibuffer.  (The debugger shows `read' called with nil as
arg, but the doc of `read' says that it uses the minibuffer (only) when its arg
is t.)

It's also not clear where in the code emacs -Q creates the editable field
immediately, so that it can read from there, vs what I see in my setup, which is
that there is no editable field at first and the first `read' takes place in the
minibuffer.