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 20:01:45 -0700 (PDT) Message-ID: <91f3ab85-e033-4e1d-a3c2-66c964ea82bc@default> 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 1473217366 11603 195.159.176.226 (7 Sep 2016 03:02:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 03:02:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 05:02:42 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 1bhT8D-0001ax-5r for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 05:02:33 +0200 Original-Received: from localhost ([::1]:37498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhT8B-00083r-5B for ged-emacs-devel@m.gmane.org; Tue, 06 Sep 2016 23:02:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhT7e-00083l-8c for emacs-devel@gnu.org; Tue, 06 Sep 2016 23:01:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhT7Y-00029N-UO for emacs-devel@gnu.org; Tue, 06 Sep 2016 23:01:58 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:31763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhT7Y-00029J-Lq for emacs-devel@gnu.org; Tue, 06 Sep 2016 23:01:52 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u8731o7n016587 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Sep 2016 03:01:51 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u8731oqN007565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Sep 2016 03:01:50 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u8731mFA025664; Wed, 7 Sep 2016 03:01:49 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: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:207237 Archived-At: I wasn't as clear as I should have been.=20 > > 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). >=20 > For S-exps in general, we can't provide much completion, and we > certainly shouldn't provide completion against function names and > variable names. >=20 > 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. Your analogy is OK. I wouldn't speak of an "Elisp expression" here, since to me that just means any expression - sexp that you can construct with Emacs Lisp. But now I know what you mean. It's not about any intention to evaluate; your speaking of that was throwing me off. I was really asking only about getting the extra hyphen removed from `read--expression'. ;-) Use cases I have for it do involve sometimes immediately evaluating the sexp read, but sometimes they involve putting such sexps together to form larger sexps (which sometimes might be evaluated at some point). I don't have a problem with the completion that `read-expression' provides, and in many such use cases the names to complete are indeed names of program parts - in particular names of functions and variables. This, in spite of the fact that the sexps read need not be evaluable without error. For more general sexps - your XML (S-exp) level of generality, there is completion against an obarray. And in some intermediate cases `dabbrev' completion (names from one or more buffers) can be helpful. When Elisp buffers are involved, it too can be about reading bits of potential code. In this thread I was really only talking about `read--expression' and what it does. What it does is useful also to ordinary Emacs user-programmers, not just "internally". > > The non-"internal" function `read-minibuffer' is not very > > reasonable, and is essentially a vestige, at this point. >=20 > 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. See above. Any Lisp sexp can be related to Elisp code. Any data can be a piece of some code. But yes, I was interested here in what `read--expression' does already. > > We can do better, and better is already available: > > `read--expression'. Some such function should now be > > available non-"internally". >=20 > 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. >=20 > > 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. >=20 > I have no idea what a "read-expression not for eval" would mean or look > like. It's what Davis was trying to distinguish `read--expression' as: reading an expression "intended for evaluation" (paraphrasing). Likewise, you. You both tried to distinguish what it does as reading an expression that might be evaluated (even though it can also read expressions that cannot, without raising an error). Creating variants of the behavior was his idea. I'm fine with the current behavior (which I don't associate directly with evaluation, but which I recognize provides completion against known functions and variables). > `read--expression' already couldn't care less whether you'll > pass the result to `eval' or not. Thank you. That's what I was saying. It is you (and Davis) who used "evaluation" to characterize it. > 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. Even that assumption is too strong (see above), but I don't know a great way to characterize it. I'd say that the completion against existing function (after `(' ) and variable names sums it up, but I don't have a name for that. "Expression" doesn't say more than "sexp", to me - it's just as general. > > 1. That's not a good reason to make it "internal". >=20 > I already said that it's internal for no particular reason. Not really. You said that it's internal because it's easier to later make a name non-internal than the reverse. Which is true, but which is not a great reason, in itself: it would apply to every new function. I submitted bug report #24386 to get rid of the "internal" characterization.