From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: `read--expression' and `read-minibuffer' Date: Tue, 6 Sep 2016 13:29:03 -0700 (PDT) Message-ID: References: <60e5e890-6f50-4f38-a74f-e82ff83b24dc@default> <8e6be928-75ae-4714-bf03-d6505954cf21@default> <10888855-8ce3-648f-82ac-2b9e1409effc@lanl.gov> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1473201502 4566 195.159.176.226 (6 Sep 2016 22:38:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 22:38:22 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 00:38:18 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhP0N-0000FF-0l for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 00:38:11 +0200 Original-Received: from localhost ([::1]:36574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhP0L-0000cF-2e for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 18:38:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhP0D-0000Wa-TT for emacs-devel@gnu.org; Tue, 06 Sep 2016 18:38:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhP09-0005yp-Id for emacs-devel@gnu.org; Tue, 06 Sep 2016 18:38:00 -0400 Original-Received: from aserp1050.oracle.com ([141.146.126.70]:27732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhP09-0005yY-70 for emacs-devel@gnu.org; Tue, 06 Sep 2016 18:37:57 -0400 Original-Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by aserp1050.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u86KTSsR018501 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 6 Sep 2016 20:29:29 GMT Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u86KTHfU012596 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 20:29:18 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u86KTHXA026447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 20:29:17 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u86KT9xg032452; Tue, 6 Sep 2016 20:29:16 GMT In-Reply-To: <10888855-8ce3-648f-82ac-2b9e1409effc@lanl.gov> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserp1040.oracle.com [141.146.126.69] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.70 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207231 Archived-At: > >> Because it is tailored for that use case. The kind of completion > >> it provides for instance assumes the S-exp is an Elisp expression. > > > > Of course it is an Elisp expression. It does not follow that > > the Elisp expression that has been read will then be _evaluated_. >=20 > In this thread, Stefan is defining an "Elisp expression" to be > precisely an S-exp that is intended for `eval'. He may be. But that does not really correspond to the effect of `read--expression'. There is nothing in its behavior that limits what is read to expressions that are intended to be evaluated. > > Completion can be used and useful when constructing an Elisp > > expression to be read, regardless of whether the expression > > that is read will be evaluated, or can be evaluated without > > error. >=20 > So a variant of `read--expression' could be written that does a subset > of that completion appropriate to the more general context of entering > an S-exp. It might for instance be a flag passed to `read--expression'. See above. What is read and returned is an arbitrary sexp, not one that is supposedly intended only for evaluation. Perhaps you are referring to the fact that after `(' a symbol is completed against only function names, instead of against both function and variable names? That's not a real problem, but that's the only place/case where I can see an argument for a "variant" behavior (completion against both function and variable names at that position too). Or perhaps you are referring to the fact that `read--expression' runs `eval-expression-minibuffer-setup-hook' functions at the outset? If you want to bother creating a variant for completing both function and variable symbols, and for not running that eval-intended hook, I don't have a problem with that. The point is to get a reasonably behaving read function for sexps that is not branded "internal". The non-"internal" function `read-minibuffer' is not very reasonable, and is essentially a vestige, at this point. And there is little sense in otherwise asking users to roll their own, e.g., using just `read-from-minibuffer' with `read-expression-map' and `read-expression-history'. We can do better, and better is already available: `read--expression'. Some such function should now be available non-"internally". If you want to (1) rename the current `read--expression' to `read-expression-for-eval' and (2) create a variant `read-expression' (which is for both eval and not), please go ahead. Or if you want to roll those together, distinguishing the behaviors by an optional arg, please go ahead. > This answers your original question: it's internal because we are > still discovering the use cases and desirable interface for it. 1. That's not a good reason to make it "internal". If you want to learn more about use cases and improving the interface then make it non-"internal". Users are best placed to tell you about both of those things. The function has been available for almost 3 years "internally". Do you really think more time to just ponder it "internally" is what is called for, to "discover the use cases and desirable interface"? 2. That "reason" applies to ALL new functions. It's hardly a solid reason. It's not a reason why _this_ function should be "internal". 3. The same (#2) applies to the only other reason given so far (by Stefan), which was that it is easier to make an existing function become non-"internal" than it is to make it become "internal". That "reason" too applies to ALL new functions. What would _you_ choose, to read an arbitrary Lisp expression in the minibuffer? Would you really choose the non-"internal" function `read-minibuffer'? Not if you wanted to help the users whose input was being read. Or would you use just `read-from-minibuffer', passing `read-expression-map' and `read-expression-history'? (`read-expression-map' and `read-expression-history' have been around since the beginning (Emacs 20, anyway), for reading sexps.) Time to plant this little one outside, in the wide world beyond the hothouse/incubator, I'd say.