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 20:04: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 1473206549 16074 195.159.176.226 (7 Sep 2016 00:02:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 00:02:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 02:02:26 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 1bhQJm-000313-PB for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 02:02:18 +0200 Original-Received: from localhost ([::1]:36849 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhQJk-0003Ah-FW for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 20:02:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhQJA-0003Ab-Vk for emacs-devel@gnu.org; Tue, 06 Sep 2016 20:01:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhQJ4-0003ax-VL for emacs-devel@gnu.org; Tue, 06 Sep 2016 20:01:40 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhQJ4-0003a7-Pc for emacs-devel@gnu.org; Tue, 06 Sep 2016 20:01:34 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u8701VDN011141; Tue, 6 Sep 2016 20:01:31 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 15E0E66340; Tue, 6 Sep 2016 20:04:45 -0400 (EDT) In-Reply-To: (Drew Adams's message of "Tue, 6 Sep 2016 13:29:03 -0700 (PDT)") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5789=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5789> : inlines <5189> : streams <1696435> : uri <2283572> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:207234 Archived-At: > 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). For S-exps in general, we can't provide much completion, and we certainly shouldn't provide completion against function names and variable names. An S-exp is like an XML tree. An Elisp expression is like a XHTML tree (i.e. it's a particular kind of XML that is expected to follow a particular schema). Yes, it's also an XML tree, but if all you know is that you're typing an XML tree, providing any completion based on XHTML identifiers is just bogus. > The non-"internal" function `read-minibuffer' is not very > reasonable, and is essentially a vestige, at this point. Ah, so that's your complaint. Why don't you make a bug-report about that one, pointing out exactly what are its shortcomings. But do remember: it's a function meant for S-exps, i.e. random data represented in a form suitable for the Lisp reader, with no assumption like an expectation that it be related to Elisp code. > We can do better, and better is already available: > `read--expression'. Some such function should now be > available non-"internally". Now I'm confused. If you want a function to read an Elisp expression, indeed read--expression might be your solution. Then make a bug report asking for it to be renamed. > 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. I have no idea what a "read-expression not for eval" would mean or look like. `read--expression' already couldn't care less whether you'll pass the result to `eval' or not. All it cares about is that it provides useful behavior (eldoc, completion, indentation) under the assumption that the user is typing something that is (more or less) valid Elisp code, rather than random data. > 1. That's not a good reason to make it "internal". I already said that it's internal for no particular reason. So at this point I'll just PLONK Stefan