From: Robert Weiner <rsw@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 29763@debbugs.gnu.org
Subject: bug#29763: New Feature: Remove unneeded eval-expression in minibuffer-history
Date: Mon, 18 Dec 2017 18:04:18 -0500 [thread overview]
Message-ID: <CA+OMD9gzKMyYTm-r9Pp2a8am1=5S=CbXovVTpoaGFTvC7UO02w@mail.gmail.com> (raw)
In-Reply-To: <83wp1kox7r.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
On Mon, Dec 18, 2017 at 10:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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-:. 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 parentheses
> 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?
Because if you remove the eval-expression wrapper, it still evaluate
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.
>
> We
>
>
> have a uniform behavior of "C-x ESC ESC" with all the commands
I figured that would come up. Redo 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.
>
>
> Moreover, "M-x list-command-history" also shows the above expanded
>
> forms.
>
Right, 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, it won't
matter at that point.
> One could argue whether showing Lisp instead of something similar to
>
> what the user actually typed is a good idea, whether it's educational
>
> or not, but this is very old and consistent behavior. If we are going
>
> to change that, I think the change should affect more than just M-:,
>
> and should probably be an optional feature.
>
I 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
[-- Attachment #2: Type: text/html, Size: 6853 bytes --]
next prev parent reply other threads:[~2017-12-18 23:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 4:13 bug#29763: New Feature: Remove unneeded eval-expression in minibuffer-history Robert Weiner
2017-12-18 15:46 ` Eli Zaretskii
2017-12-18 23:04 ` Robert Weiner [this message]
2017-12-22 10:28 ` Eli Zaretskii
2019-06-24 20:25 ` Lars Ingebrigtsen
2019-06-27 2:29 ` Robert Weiner
2017-12-22 12:16 ` Tomas Nordin
2017-12-22 12:58 ` Andreas Schwab
2017-12-22 14:21 ` Robert Weiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+OMD9gzKMyYTm-r9Pp2a8am1=5S=CbXovVTpoaGFTvC7UO02w@mail.gmail.com' \
--to=rsw@gnu.org \
--cc=29763@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=rswgnu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.