From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#29763: New Feature: Remove unneeded eval-expression in minibuffer-history Date: Mon, 18 Dec 2017 18:04:18 -0500 Message-ID: References: <83wp1kox7r.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113fdc8a8d60e20560a56049" X-Trace: blaine.gmane.org 1513638258 13415 195.159.176.226 (18 Dec 2017 23:04:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Dec 2017 23:04:18 +0000 (UTC) Cc: 29763@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 19 00:04:14 2017 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 1eR4SD-00039S-PR for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Dec 2017 00:04:14 +0100 Original-Received: from localhost ([::1]:51876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eR4UB-0007VJ-R4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Dec 2017 18:06:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eR4U2-0007Ty-OV for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2017 18:06:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eR4Tz-0007U4-Cu for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2017 18:06:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60484) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eR4Tz-0007Tc-9A for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2017 18:06:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eR4Ty-0007sc-95 for bug-gnu-emacs@gnu.org; Mon, 18 Dec 2017 18:06:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Dec 2017 23:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29763 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 29763-submit@debbugs.gnu.org id=B29763.151363830330213 (code B ref 29763); Mon, 18 Dec 2017 23:06:02 +0000 Original-Received: (at 29763) by debbugs.gnu.org; 18 Dec 2017 23:05:03 +0000 Original-Received: from localhost ([127.0.0.1]:40932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eR4T0-0007r7-8i for submit@debbugs.gnu.org; Mon, 18 Dec 2017 18:05:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34143) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eR4Sx-0007qg-EM for 29763@debbugs.gnu.org; Mon, 18 Dec 2017 18:04:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eR4So-0006GB-8l for 29763@debbugs.gnu.org; Mon, 18 Dec 2017 18:04:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eR4So-0006G0-3l for 29763@debbugs.gnu.org; Mon, 18 Dec 2017 18:04:50 -0500 Original-Received: from mail-qt0-f182.google.com ([209.85.216.182]:36476) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eR4Sn-0007hH-QG for 29763@debbugs.gnu.org; Mon, 18 Dec 2017 18:04:49 -0500 Original-Received: by mail-qt0-f182.google.com with SMTP id a16so22118142qtj.3 for <29763@debbugs.gnu.org>; Mon, 18 Dec 2017 15:04:49 -0800 (PST) X-Gm-Message-State: AKGB3mIfC0Ym0CqGXvrBDJXudT+lZoEMmbhA6C1xp4Ym1iJ6pqULLCLr SPfCjV8RcKJqVkP616yLXMqNMPmYi+xAAiBFDgE= X-Google-Smtp-Source: ACJfBott7NPIu95Kvz9S/UvfVXwdYE/48Ab6A+g3C0aki87E0vNorFxXJPvR0CKElGPT1RHoQuKAyqLogtlo+v2X7sg= X-Received: by 10.200.45.93 with SMTP id o29mr2279873qta.22.1513638289300; Mon, 18 Dec 2017 15:04:49 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Mon, 18 Dec 2017 15:04:18 -0800 (PST) In-Reply-To: <83wp1kox7r.fsf@gnu.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:141237 Archived-At: --001a113fdc8a8d60e20560a56049 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 18, 2017 at 10:46 AM, Eli Zaretskii wrote: > > From: Robert Weiner > > Date: Sun, 17 Dec 2017 23:13:17 -0500 > > > > For as long as I can remember, I have wanted the minibuffer history to > > strip the eval-expression wrapper around expressions that I enter by > > invoking eval-expression with M-:. I want this because the wrapper > > adds a lot of visual noise when searching for a specific expression and > > makes it much harder to edit the expression and get trailing parenthese= s > right. > > > > So if I enter: > > > > M-: (/ 1.0 9) RET > > > > then C-x ESC ESC shows me: > > > > (eval-expression (quote (/ 1.0 9)) nil nil 127) > > > > but I want to see just the expression that I want to reuse or edit: > > > > (/ 1.0 9) > > Hmm... why is this particular command (M-:) being singled out? =E2=80=8BBecause if you remove the eval-expression wrapper, it still evalua= te to the same thing. That is not the case for most other commands as you can see from the examples you provided. I did, however, imagine that other forms might be added to the one function that pairs a command down and we could make it a variable activated with a funcall if desired. =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > We > =E2=80=8B > =E2=80=8B=E2=80=8B > have a uniform behavior of "C-x ESC ESC" with all the commands =E2=80=8B=E2=80=8B =E2=80=8BI figured that would come up. =E2=80=8BRedo behavior won't change= , just whether a full command or an Lisp form is displayed. I should note that someone pointed out that {M-: M-p} does what I want already, so one option is to retrain the muscle memory to that key, though that does not help with use of list-command-history as discussed below. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > Moreover, "M-x list-command-history" also shows the above expanded > =E2=80=8B=E2=80=8B > forms. > =E2=80=8BRight, when looking through a list-command-history, it would be much faster to find expressions without the wrapper even though now they would just be forms and not commands. Since the redo code already does an eval of each element=E2=80=8B, it won't matter at that point. =E2=80=8B=E2=80=8B > One could argue whether showing Lisp instead of something similar to > =E2=80=8B=E2=80=8B > what the user actually typed is a good idea, whether it's educational > =E2=80=8B=E2=80=8B > or not, but this is very old and consistent behavior. If we are going > =E2=80=8B=E2=80=8B > to change that, I think the change should affect more than just M-:, > =E2=80=8B=E2=80=8B > and should probably be an optional feature. > =E2=80=8BI agree with that. Think about it and decide whether such a change would likely make it acceptable for merging. If so, we can make more edits, if not, we should drop it. Bob =E2=80=8B =E2=80=8B=E2=80=8B --001a113fdc8a8d60e20560a56049 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 18, 2= 017 at 10:46 AM, Eli Zaretskii <e= liz@gnu.org> wro= te:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> From: Robert Weiner <rsw@gnu.org>
> Date: Sun, 17 Dec 2017 23:13:17 -0500
>
> For as long as I can remember, I have wanted the minibuffer history to=
> strip the eval-expression wrapper around expressions that I enter by > invoking eval-expression with M-:.=C2=A0 I want this because the wrapp= er
> adds a lot of visual noise when searching for a specific expression an= d
> makes it much harder to edit the expression and get trailing parenthes= es right.
>
> So if I enter:
>
>=C2=A0 =C2=A0M-: (/ 1.0 9) RET
>
> then C-x ESC ESC shows me:
>
>=C2=A0 =C2=A0(eval-expression (quote (/ 1.0 9)) nil nil 127)
>
> but I want to see just the expression that I want to reuse or edit: >
>=C2=A0 =C2=A0(/ 1.0 9)

Hmm... why is this particular command (M-:) being singled out?=C2=A0

=E2=80=8BBecause if you remove the eval-expression wr= apper, it still evaluate
to the same thing.=C2=A0 That is not the case for= most other commands as
you can see from the examples you provided.
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">
<= /div>
I did, however, imagine that other forms might be added to the
one functi= on that pairs a command down and we could make it a variable
activated wit= h a funcall if desired.
=E2=80=8B=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
We
=E2=80= =8B=C2=A0
=E2=80=8B=E2=80=8B
have a uniform behavior o= f "C-x ESC ESC" with all the commands
=E2=80=8B=E2= =80=8B
=E2=80=8BI figured that would come up.=C2=A0 =E2=80=8BRedo behavior= won't change,
just whether a full command or an Lisp form i= s displayed.

I should note that someone pointed out that {M-: M-p} d= oes
what I want already, so one option is to retrain the muscle
memory to= that key, though that does not help with use of
list-command-history as d= iscussed below.


=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
Moreo= ver, "M-x list-command-history" also shows the above expanded
=E2=80=8B=E2=80=8B
forms.

=E2=80= =8BRight, when looking through a list-command-history, it would
be much fa= ster to find expressions without the wrapper even
though now they would ju= st be forms and not commands.=C2=A0 Since
the redo code already does an ev= al of each element=E2=80=8B, it won't
matter at that point.

=E2=80=8B=E2=80=8B
One could argue whether showing Lisp ins= tead of something similar to
=E2=80=8B=E2=80=8B
what the user actually typed is a good i= dea, whether it's educational
=E2=80=8B=E2=80=8B
or not, but this is very old and consist= ent behavior.=C2=A0 If we are going
=E2=80=8B=E2=80=8B
to change that, I think the change shoul= d affect more than just M-:,
=E2=80=8B=E2=80=8B
and should probably be an optional featu= re.

=E2=80=8BI agree with that.=C2=A0 Think abou= t it and decide whether such
a change would likely make it acceptable for = merging.=C2=A0 If so,
we can make more edits, if not, we should drop it.
=
Bob
=E2=80=8B
=E2=80=8B=E2=80=8B

--001a113fdc8a8d60e20560a56049--