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
​
​​