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 14:35:13 -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 1473197768 21029 195.159.176.226 (6 Sep 2016 21:36:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 21:36:08 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 06 23:36:04 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 1bhO2C-0004bU-Tn for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 23:36:01 +0200 Original-Received: from localhost ([::1]:36093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhO2A-0007v3-Mu for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 17:35:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhO1W-0007sz-Kh for emacs-devel@gnu.org; Tue, 06 Sep 2016 17:35:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhO1V-0007ht-L6 for emacs-devel@gnu.org; Tue, 06 Sep 2016 17:35:18 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:36379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhO1V-0007hd-Bh for emacs-devel@gnu.org; Tue, 06 Sep 2016 17:35:17 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u86LZFa6002295 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 21:35:16 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u86LZFIY028960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 21:35:15 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u86LZE5C015431; Tue, 6 Sep 2016 21:35:15 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:207222 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_. > > In this thread, Stefan is defining an "Elisp expression" to be precisel= y > > an S-exp that is intended for `eval'. >=20 > Not necessarily directly for `eval', but yes an Elisp expression as > opposed to random S-exp data. E.g. when reading an alist, you shouldn't > use read--expression (whereas, when reading an expression that will > evaluate to an alist, read--expression is probably the right thing to > use). >=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. >=20 > For any random S-exp data, we already have `read-minibuffer', so I don't > see any point in changing read--expression to cover that case. Completion of parts of the data. Just as in the function-application sexp case. There just is assumption that the first symbol after `(' should complete against only function symbols.