GNU logs - #12066, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt
Resent-From: "Drew Adams" <drew.adams@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 27 Jul 2012 06:04:02 +0000
Resent-Message-ID: <handler.12066.B.134336900414361 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 12066 <at> debbugs.gnu.org
From: "Drew Adams" <drew.adams@HIDDEN>
Date: Thu, 26 Jul 2012 22:56:13 -0700
Message-ID: <8071B1FC8E764E37AA6BE5474AD5A563@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Ac1rvIcyPdOfiGG1TA+CYS9+pC/8Ag==
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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'

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.428 (Entity 5.428)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Drew Adams" <drew.adams@HIDDEN>
Subject: bug#12066: Acknowledgement (24.1; Customize :type `restricted-sexp'
 :tag - use it for prompt)
Message-ID: <handler.12066.B.134336900414361.ack <at> debbugs.gnu.org>
References: <8071B1FC8E764E37AA6BE5474AD5A563@HIDDEN>
X-Gnu-PR-Message: ack 12066
X-Gnu-PR-Package: emacs
Reply-To: 12066 <at> debbugs.gnu.org
Date: Fri, 27 Jul 2012 06:04:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 12066 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
12066: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12066
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt
Resent-From: Andreas Schwab <schwab@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 27 Jul 2012 08:10:01 +0000
Resent-Message-ID: <handler.12066.B12066.134337655125352 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Drew Adams" <drew.adams@HIDDEN>
Cc: 12066 <at> debbugs.gnu.org
From: Andreas Schwab <schwab@HIDDEN>
References: <8071B1FC8E764E37AA6BE5474AD5A563@HIDDEN>
Date: Fri, 27 Jul 2012 10:02:10 +0200
In-Reply-To: <8071B1FC8E764E37AA6BE5474AD5A563@HIDDEN> (Drew Adams's
	message of "Thu, 26 Jul 2012 22:56:13 -0700")
Message-ID: <m2a9ylpr7h.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

"Drew Adams" <drew.adams@HIDDEN> writes:

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

That's not a sexp.

Andreas.

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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt
Resent-From: "Drew Adams" <drew.adams@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 27 Jul 2012 09:35:02 +0000
Resent-Message-ID: <handler.12066.B12066.13433816863751 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: <12066 <at> debbugs.gnu.org>
From: "Drew Adams" <drew.adams@HIDDEN>
References: <8071B1FC8E764E37AA6BE5474AD5A563@HIDDEN>
Date: Fri, 27 Jul 2012 02:27:41 -0700
Message-ID: <7B2264BA4D104FA488427D8664FF5665@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <8071B1FC8E764E37AA6BE5474AD5A563@HIDDEN>
Thread-Index: Ac1rvIcyPdOfiGG1TA+CYS9+pC/8AgAGjUOQ
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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=01!\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) (=3D 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) (=3D 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) (=3D 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.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.