From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#32064: 26; doc string of `eval-last-sexp' Date: Fri, 6 Jul 2018 10:55:19 -0700 (PDT) Message-ID: <128a3332-b4cf-4e6b-b435-8215fee9928d@default> References: <0d7bb132-057e-431e-a5fa-86e15b99879a@default> <87bmbldxg3.fsf@gmail.com> <83va9sln3t.fsf@gnu.org> <877em8egby.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1530899647 4223 195.159.176.226 (6 Jul 2018 17:54:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 17:54:07 +0000 (UTC) Cc: 32064@debbugs.gnu.org To: Noam Postavsky , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 06 19:54:02 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1fbUvi-0000z4-Fq for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Jul 2018 19:54:02 +0200 Original-Received: from localhost ([::1]:59178 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbUxp-0000yH-F4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Jul 2018 13:56:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbUxi-0000xA-9t for bug-gnu-emacs@gnu.org; Fri, 06 Jul 2018 13:56:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbUxf-0001I3-5T for bug-gnu-emacs@gnu.org; Fri, 06 Jul 2018 13:56:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40919) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbUxf-0001Hj-0r for bug-gnu-emacs@gnu.org; Fri, 06 Jul 2018 13:56:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fbUxe-0005Rg-G7 for bug-gnu-emacs@gnu.org; Fri, 06 Jul 2018 13:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Jul 2018 17:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32064 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32064-submit@debbugs.gnu.org id=B32064.153089973420897 (code B ref 32064); Fri, 06 Jul 2018 17:56:02 +0000 Original-Received: (at 32064) by debbugs.gnu.org; 6 Jul 2018 17:55:34 +0000 Original-Received: from localhost ([127.0.0.1]:48816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fbUxC-0005Qx-0J for submit@debbugs.gnu.org; Fri, 06 Jul 2018 13:55:34 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:46438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fbUxA-0005Ql-Lc for 32064@debbugs.gnu.org; Fri, 06 Jul 2018 13:55:33 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w66Hs5I4188631; Fri, 6 Jul 2018 17:55:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Us1Eu3cezwi2A9E5KFDtDG2tioqMi06Fkr+iytLsDL0=; b=Ltq8aO8AeXavVucr5+In4yBuQhrlnX/mqZdk2YM9u7h/GlOVAlJpqDYIP7ajnUL9CD7f FpQCWpocb/LVtvLUP27L+/BhhwsnCkgNN3D+JHXqTetGSyqWRJFwP7NIfXGKkAndB6Sl 52VUYIfczPhQOHmcTC/Y+YC4Qr3dwjTIvb8Q0BbyINF5lIYAAzL7nFuTVl+cbm/HAWev QR3PtAtNkLETbw4FKSoEi4Z+wdBqi0eybyRI8bokfcU0TDuFizL2FnBMxkb9JBhKOCG/ rp9juHHwW9HAOg1ul39wN8bQuxBIrM1aLYaLzQ1t3gPa1e6b7KW/j/7flj3vVztfowvN bg== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2k0dnjtjgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 06 Jul 2018 17:55:26 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w66HtPiQ007726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 6 Jul 2018 17:55:25 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w66HtNd8007787; Fri, 6 Jul 2018 17:55:24 GMT In-Reply-To: <877em8egby.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4705.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8945 signatures=668704 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060199 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:148268 Archived-At: > >> I agree. I think the solution is to simplify the interface somewhat. > > > > These additional features weer added just recently, so I see no reason > > why we should remove them now. Certainly not because the doc string > > needs to be fixed. >=20 > >> As it stands, we're trying to cram a lot of functionality into the > >> prefix argument, and the encoding is too difficult to remember (both > >> in terms of implementing & documenting, as well as for using). > > > > I had no difficulty bringing the doc string in line with the > > implementation, please take a look. >=20 > Thanks, I think that fixes all the typos and mistaken descriptions. I > am still of the opinion that the prefix args apart from C-u are too > complicated to be of much use. But we can wait a bit longer and maybe > the next formatting feature will be the straw that breaks the proverbial > camel's back. Thanks for the doc string corrections. I agree with Noam that the behavior is not great. It's not very user-friendly or very useful. It should be rethought, even at the cost of backward incompatibility. Perhaps a new, replacement command should be added and given the key binding, keeping the old command available for whoever wants to restore its binding. I started to write a mail to emacs-devel about this yesterday, but I dropped it, at least for now. FWIW, I think it would be good if the various Lisp evaluation commands acted more or less similarly - e.g., wrt a prefix arg. There are several, including: `eval-last-sexp', `eval-print-last-sexp', `pp-eval-last-sexp', `eval-expression', `pp-eval-expression', `eval-region', `eval-defun', `eval-buffer', and `lisp-eval-defun' Something I've been thinking about is the need I have to evaluate Lisp code with `lexical-binding' optionally non-nil. I know that the expectation of some (maybe all) is that Emacs will eventually make non-nil the default value of `lexical-binding', or even remove the variable altogether and make binding lexical by default (the same effect as having the variable default to non-nil everywhere, but with no ability to change the behavior to what nil gives). FWIW, I have no problem with that, as long as dynamic binding is still available - exactly the situation of Common Lisp, and _not_ the situation of Scheme. Still, it is now, and it can remain in the future, useful to be able to grab a bit of code from anywhere and evaluate it optionally with `lexical-binding' in effect. I sometimes copy Lisp code from files I'm working on to another Lisp buffer, to modify and experiment with. The buffer I copy it to might serve for code that comes from buffers with nil and non-nil `lexical-binding'. And it might not be a file buffer, or I might not have bothered to add a local-variable declaration for it. E.g. `C-x 4 f foo.el', for a non-existent file `foo.el', does not default to non-nil `lexical-binding' (yes, I could make it do that). When I want to evaluate bits of code in such a test buffer, it won't do to just use `eval-region' or `eval-expression' or `eval-last-sexp'. Depending on whether the code to be eval'd _depends on_ lexical binding, I need to first set `lexical-binding' as needed, perhaps temporarily, for the whole buffer. I'd prefer to have the evaluation commands take care of this. I can of course define separate commands for lexical binding, like so: (defun eval-region-lexical (start end &optional printflag read-function) "..." (interactive "r") (let ((lexical-binding t)) (eval-region start end printflag read-function))) But it would be handy if the regular commands would let me provide a prefix arg to get that behavior. E.g.: (defun eval-region (start end &optional printflag read-function lexicalp) "..." (interactive "r\ni\ni\nP") (let ((lexical-binding (if lexicalp t lexical-binding))) (eval-region start end printflag read-function))) That would work for `eval-region', because it currently defines no prefix-arg behavior. But for the other eval commands things are less simple. They already use prefix args to the max (too much). Like Noam, I'd argue that the prefix arg behavior for some of them is far too complex, if not tricky. The resulting doc is consequently pretty much a mess. Can we come up with something better? Maybe there needs to be more than one command for some of these things that are currently combined via prefix args (again, something that Noam too suggested)? Or maybe some better combinations can be found? You'll note that I included the `pp-eval-*' commands in the list above. I bind (a variant of) `pp-eval-expression' to `M-:', for instance. I'd like `pp-eval-*' commands to also share in a reflection about better and more consistent prefix-arg behavior. --- FWIW, my variant of `pp-eval-expression' does the following. I mention it for the info about prefix-arg behavior. IOW, I realize that different eval commands can have different uses for a prefix arg. Still, some more consistency, and less complexity, than now would help. - Read with completion, using `pp-read-expression-map', which is like `read-expression-map' but with some Emacs-Lisp key bindings. - Respect option `eval-expression-debug-on-error'. - With no prefix arg, respect option `pp-max-tooltip-size'. If a tooltip is not used then if the value fits on one line (frame width) show it in the echo area. Otherwise, show it in buffer *Pp Eval Output*'. - With a zero prefix arg, swap the use of a tooltip according to `pp-max-tooltip-size': if that option is `nil' then use a tooltip; if non-`nil' then do not use a tooltip. - With non-zero prefix arg, insert the value into the current buffer at point. With a negative prefix arg, if the value is a string then insert it without enclosing double-quotes (").