[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29763: New Feature: Remove unneeded eval-expression in minibuffer-hi

From: Robert Weiner
Subject: bug#29763: New Feature: Remove unneeded eval-expression in minibuffer-history
Date: Mon, 18 Dec 2017 18:04:18 -0500

On Mon, Dec 18, 2017 at 10:46 AM, Eli Zaretskii <address@hidden> wrote:
> From: Robert Weiner <address@hidden>
> 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.
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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]