From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: `read--expression' and `read-minibuffer' Date: Tue, 06 Sep 2016 17:05:45 -0400 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 X-Trace: blaine.gmane.org 1473197061 3934 195.159.176.226 (6 Sep 2016 21:24:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 21:24:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 06 23:24:17 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 1bhNqn-0008Vb-BH for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 23:24:13 +0200 Original-Received: from localhost ([::1]:35964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhNql-0006uZ-0x for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 17:24:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhNlA-0002x4-E7 for emacs-devel@gnu.org; Tue, 06 Sep 2016 17:18:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhNl9-0000mC-Uy for emacs-devel@gnu.org; Tue, 06 Sep 2016 17:18:24 -0400 Original-Received: from [195.159.176.226] (port=56595 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhNl9-0000jg-OC for emacs-devel@gnu.org; Tue, 06 Sep 2016 17:18:23 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bhNVs-0004Cz-J4 for emacs-devel@gnu.org; Tue, 06 Sep 2016 23:02:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 22 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:YIAUd+nK7PGlkgElXHLoGdmsJq0= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:207219 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 precisely an > S-exp that is intended for `eval'. 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). > 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. 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. Stefan