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

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

[Robert Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 816 bytes --]

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)

This small patch against Emacs 27.0.50  gives me that; it does the same
removal for commands already in the history if you load the change in
the middle of an Emacs session.  Please consider adding it to Emacs; it is
already improving my productivity.

Bob

[-- Attachment #1.2: Type: text/html, Size: 2605 bytes --]

[-- Attachment #2: simple.el.patch --]
[-- Type: application/octet-stream, Size: 1616 bytes --]

*** simple-orig.el.gz	2017-12-17 22:54:50.000000000 -0500
--- simple.el.gz	2017-12-17 22:54:50.000000000 -0500
***************
*** 1563,1572 ****
--- 1563,1580 ----
                          (eval-expression-print-format (car values)))))
            (when str (princ str out)))))))
  
+ (defun minibuffer-history-edit-element (elt)
+   "Automatically simplify ELT if possible, e.g. removing eval-expression."
+   (or (and (consp elt) (eq (car elt) 'eval-expression)
+ 	   ;; Remove eval-expression wrapper and leave just the expression.
+ 	   (cadadr elt))
+       elt))
+ 
  (defun edit-and-eval-command (prompt command)
    "Prompting with PROMPT, let user edit COMMAND and eval result.
  COMMAND is a Lisp expression.  Let user edit that expression in
  the minibuffer, then read and evaluate the result."
+   (setq command (minibuffer-history-edit-element command))
    (let ((command
  	 (let ((print-level nil)
  	       (minibuffer-history-sexp-flag (1+ (minibuffer-depth))))
***************
*** 1601,1606 ****
--- 1609,1615 ----
  	newcmd)
      (if elt
  	(progn
+ 	  (setq elt (minibuffer-history-edit-element elt))
  	  (setq newcmd
  		(let ((print-level nil)
  		      (minibuffer-history-position arg)
***************
*** 2070,2075 ****
--- 2079,2085 ----
  	   (setq minibuffer-text-before-history nil))
  	  (t (setq elt (nth (1- minibuffer-history-position)
  			    (symbol-value minibuffer-history-variable)))))
+     (setq elt (minibuffer-history-edit-element elt))
      (insert
       (if (and (eq minibuffer-history-sexp-flag (minibuffer-depth))
  	      (not minibuffer-returned-to-present))

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

[Eli Zaretskii]

> 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?  We
have a uniform behavior of "C-x ESC ESC" with all the commands: they
are stored and displayed as the equivalent Lisp expressions.  E.g.:

  C-x C-f ~/foo/bar RET
  C-x ESC ESC
     -| Redo: (find-file "~/foo/bar" t)

or even

  M-x set-variable RET auto-hscroll-mode RER current-line RET
  Cx ESC ESC
     -| Redo: (set-variable (quote auto-hscroll-mode) (quote current-line) nil)

Moreover, "M-x list-command-history" also shows the above expanded
forms.

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.

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

[Robert Weiner]

[-- 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 --]

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

[Eli Zaretskii]

> From: Robert Weiner <rsw@gnu.org>
> Date: Mon, 18 Dec 2017 18:04:18 -0500
> Cc: 29763@debbugs.gnu.org
> 
>  ​​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.

IMO, such an option could be useful, but I'm puzzled by the lack of
any comments from others.  Not sure what does that mean.

Thanks.

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

[Tomas Nordin]

Robert Weiner <rsw@gnu.org> writes:

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

As a user I can easily agree on this idea.

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

[Andreas Schwab]

On Dez 17 2017, Robert Weiner <rsw@gnu.org> wrote:

> + (defun minibuffer-history-edit-element (elt)
> +   "Automatically simplify ELT if possible, e.g. removing eval-expression."
> +   (or (and (consp elt) (eq (car elt) 'eval-expression)
> + 	   ;; Remove eval-expression wrapper and leave just the expression.
> + 	   (cadadr elt))

That mishandles self-evaluating expressions, they are not wrapped with
quote.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Robert Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 833 bytes --]

On Fri, Dec 22, 2017 at 7:58 AM, Andreas Schwab <schwab@linux-m68k.org>
wrote:

> On Dez 17 2017, Robert Weiner <rsw@gnu.org> wrote:
>
> > + (defun minibuffer-history-edit-element (elt)
> > +   "Automatically simplify ELT if possible, e.g. removing
> eval-expression."
> > +   (or (and (consp elt) (eq (car elt) 'eval-expression)
> > +        ;; Remove eval-expression wrapper and leave just the expression.
> > +        (cadadr elt))
>
> That mishandles self-evaluating expressions, they are not wrapped with
> quote.
>

​You are correct.  This version resolves that issue and changes
repeat-complex-command to use eval-expression instead of
funcall-interactively to handle expressions rather than function
calls, including properly redoing:

   (quote emacs-version)

for example.

See attached.

Bob

[-- Attachment #1.2: Type: text/html, Size: 2467 bytes --]

[-- Attachment #2: simple.el.patch --]
[-- Type: application/octet-stream, Size: 2439 bytes --]

*** simple-orig.el.gz	2017-12-22 09:15:29.000000000 -0500
--- simple.el.gz	2017-12-22 09:15:29.000000000 -0500
***************
*** 1563,1572 ****
--- 1563,1581 ----
                          (eval-expression-print-format (car values)))))
            (when str (princ str out)))))))
  
+ (defun minibuffer-history-edit-element (elt)
+   "Automatically simplify ELT if possible, e.g. removing eval-expression."
+     (when (and (consp elt) (eq (car elt) 'eval-expression))
+       (setq elt (cadr elt))
+       (when (and (consp elt) (eq (car elt) 'quote))
+ 	(setq elt (cadr elt))))
+     elt)
+ 
  (defun edit-and-eval-command (prompt command)
    "Prompting with PROMPT, let user edit COMMAND and eval result.
  COMMAND is a Lisp expression.  Let user edit that expression in
  the minibuffer, then read and evaluate the result."
+   (setq command (minibuffer-history-edit-element command))
    (let ((command
  	 (let ((print-level nil)
  	       (minibuffer-history-sexp-flag (1+ (minibuffer-depth))))
***************
*** 1601,1606 ****
--- 1610,1616 ----
  	newcmd)
      (if elt
  	(progn
+ 	  (setq elt (minibuffer-history-edit-element elt))
  	  (setq newcmd
  		(let ((print-level nil)
  		      (minibuffer-history-position arg)
***************
*** 1620,1628 ****
  	  ;; add it to the history.
  	  (or (equal newcmd (car command-history))
  	      (setq command-history (cons newcmd command-history)))
!           (apply #'funcall-interactively
! 		 (car newcmd)
! 		 (mapcar (lambda (e) (eval e t)) (cdr newcmd))))
        (if command-history
  	  (error "Argument %d is beyond length of command history" arg)
  	(error "There are no previous complex commands to repeat")))))
--- 1630,1636 ----
  	  ;; add it to the history.
  	  (or (equal newcmd (car command-history))
  	      (setq command-history (cons newcmd command-history)))
! 	  (eval-expression newcmd))
        (if command-history
  	  (error "Argument %d is beyond length of command history" arg)
  	(error "There are no previous complex commands to repeat")))))
***************
*** 2070,2075 ****
--- 2078,2084 ----
  	   (setq minibuffer-text-before-history nil))
  	  (t (setq elt (nth (1- minibuffer-history-position)
  			    (symbol-value minibuffer-history-variable)))))
+     (setq elt (minibuffer-history-edit-element elt))
      (insert
       (if (and (eq minibuffer-history-sexp-flag (minibuffer-depth))
  	      (not minibuffer-returned-to-present))

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>>  ​​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.
>
> IMO, such an option could be useful, but I'm puzzled by the lack of
> any comments from others.  Not sure what does that mean.

Me neither, but I'm not very enthusiastic about the idea.  It's kinda
nice that C-x ESC ESC gives you the unvarnished truth...  and I just
think it's kinda odd to use C-x ESC ESC on `M-:' at all: It's fewer
keystrokes to say `M-: M-p'.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Robert Weiner]

I did not know about M-: M-p and have muscle memory that drives me to press C-x ESC ESC.  I will have to retrain a bit.  You can close this issue.

-- Bob

> On Jun 24, 2019, at 4:25 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> ​​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.
>> 
>> IMO, such an option could be useful, but I'm puzzled by the lack of
>> any comments from others.  Not sure what does that mean.
> 
> Me neither, but I'm not very enthusiastic about the idea.  It's kinda
> nice that C-x ESC ESC gives you the unvarnished truth...  and I just
> think it's kinda odd to use C-x ESC ESC on `M-:' at all: It's fewer
> keystrokes to say `M-: M-p'.
> 
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no