From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#12066: 24.1; Customize :type `restricted-sexp' :tag - use it for prompt Date: Fri, 27 Jul 2012 02:27:41 -0700 Message-ID: <7B2264BA4D104FA488427D8664FF5665@us.oracle.com> References: <8071B1FC8E764E37AA6BE5474AD5A563@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1343381300 24985 80.91.229.3 (27 Jul 2012 09:28:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Jul 2012 09:28:20 +0000 (UTC) To: <12066@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 27 11:28:20 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SugqJ-0000X2-F6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jul 2012 11:28:19 +0200 Original-Received: from localhost ([::1]:57184 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SugqI-0000q5-NN for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Jul 2012 05:28:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SugqC-0000pp-V6 for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 05:28:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sugq7-00025c-0v for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 05:28:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sugq6-00025Y-U0 for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 05:28:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sugwo-0000yy-5w for bug-gnu-emacs@gnu.org; Fri, 27 Jul 2012 05:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Jul 2012 09:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12066 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12066-submit@debbugs.gnu.org id=B12066.13433816863751 (code B ref 12066); Fri, 27 Jul 2012 09:35:02 +0000 Original-Received: (at 12066) by debbugs.gnu.org; 27 Jul 2012 09:34:46 +0000 Original-Received: from localhost ([127.0.0.1]:42990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SugwY-0000yS-8u for submit@debbugs.gnu.org; Fri, 27 Jul 2012 05:34:46 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:42804) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SugwW-0000yK-3M for 12066@debbugs.gnu.org; Fri, 27 Jul 2012 05:34:44 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q6R9RjJw005916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <12066@debbugs.gnu.org>; Fri, 27 Jul 2012 09:27:46 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q6R9RiE2022125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <12066@debbugs.gnu.org>; Fri, 27 Jul 2012 09:27:45 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q6R9Rij7012673 for <12066@debbugs.gnu.org>; Fri, 27 Jul 2012 04:27:44 -0500 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Jul 2012 02:27:44 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8071B1FC8E764E37AA6BE5474AD5A563@us.oracle.com> Thread-Index: Ac1rvIcyPdOfiGG1TA+CYS9+pC/8AgAGjUOQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62456 Archived-At: 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() * #(nil) * apply(# 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.