pp-eval-expression broken

pp-eval-expression broken

[Drew Adams]

`pp-eval-expression' was apparently changed to no longer evaluate its
argument. It evaluates only when called interactively. This breaks all
Lisp calls to `pp-eval-expression' (except those with
`call-interactively).

This seems to have been changed by RMS on 2006-10-18:

 "(pp-eval-expression): Use `X' to read value.
 Non-interactive arg is the value, not the expression."

PLEASE reverse this change. Why was it made?

RE: pp-eval-expression broken

[Drew Adams]

I said:

> `pp-eval-expression' was apparently changed to no longer evaluate its
> argument. It evaluates only when called interactively. This breaks all
> Lisp calls to `pp-eval-expression' (except those with
> `call-interactively).
>
> This seems to have been changed by RMS on 2006-10-18:
>
>  "(pp-eval-expression): Use `X' to read value.
>  Non-interactive arg is the value, not the expression."
>
> PLEASE reverse this change. Why was it made?

Perhaps I shouldn't have been so strong about the request, and no doubt
there is a good reason for this change. But I'd still like to know what the
reason is.

It seems odd to me that the command would treat its arg differently, evaling
it if interactive and not evaling it otherwise. The function is
named -eval-, but it doesn't always eval.

And, as I said, this will break any existing Lisp calls to the function.
Those have been fixed in vanilla Emacs (22), but outside libraries will need
to adjust, especially if they try to work with multiple Emacs versions.

Re: pp-eval-expression broken

[Randal L. Schwartz]

>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:

Drew> Perhaps I shouldn't have been so strong about the request, and no doubt
Drew> there is a good reason for this change. But I'd still like to know what the
Drew> reason is.

Drew> It seems odd to me that the command would treat its arg differently, evaling
Drew> it if interactive and not evaling it otherwise. The function is
Drew> named -eval-, but it doesn't always eval.

Drew> And, as I said, this will break any existing Lisp calls to the function.
Drew> Those have been fixed in vanilla Emacs (22), but outside libraries will need
Drew> to adjust, especially if they try to work with multiple Emacs versions.

When I wrote pp-eval-expression, it was because I hated getting the output of
eval-expression all on one line.  I modelled it as closely as I could on the
current eval-expression, lifting the code directly, just adding my little hook
to push the output into a temp buffer, inserting return at the right places
(that was the tricky part), then letting the standard indenting stuff handle
the pretty-ing part.

I'm not addicted to the goal that it completely mimic eval-expression.
However, I'm curious about the motivation about this discontinuity. If it's to
permit a non-evalled expression be pretty-printed, that's actually quite cool,
and wouldn't make sense to be back-ported to eval-expression.

However, perhaps the motivation can be made clearer in the docstring?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

RE: pp-eval-expression broken

[Drew Adams]

> Drew> Perhaps I shouldn't have been so strong about the request,
> Drew> and no doubt there is a good reason for this change. But
> Drew> I'd still like to know what the reason is.
>
> Drew> It seems odd to me that the command would treat its arg
> Drew> differently, evaling it if interactive and not evaling it
> Drew> otherwise. The function is named -eval-, but it doesn't
> Drew> always eval.
>
> Drew> And, as I said, this will break any existing Lisp calls to
> Drew> the function. Those have been fixed in vanilla Emacs (22),
> Drew> but outside libraries will need to adjust, especially if
> Drew> they try to work with multiple Emacs versions.
>
> When I wrote pp-eval-expression, it was because I hated getting
> the output of eval-expression all on one line.

Same here! And I especially hate having a result appear in the minibuffer,
which means fishing it out of *Messages* if you want to select it.

In fact, FWIW, I re-bind M-: to `pp-eval-expression'.

(In fact, FWIW2, I even have a minibuffer binding of `M-:', so I can pp-eval
stuff on the fly, during minibuffer input.)

> I modelled it as closely as I could on the
> current eval-expression, lifting the code directly, just adding
> my little hook to push the output into a temp buffer, inserting
> return at the right places (that was the tricky part), then
> letting the standard indenting stuff handle
> the pretty-ing part.
>
> I'm not addicted to the goal that it completely mimic eval-expression.
> However, I'm curious about the motivation about this
> discontinuity. If it's to permit a non-evalled expression be
> pretty-printed, that's actually quite cool,
> and wouldn't make sense to be back-ported to eval-expression.

I hadn't thought of that.

In that case, maybe the same thing should be allowed interactively, via C-u?
And, similarly, maybe let `pp-eval-last-expression' with `C-u' do what `M-q'
does, but with the output in the *Pp Eval Output* buffer?

> However, perhaps the motivation can be made clearer in the docstring?

Agreed.

Re: pp-eval-expression broken

[Richard Stallman]

The reason for the change in pp-eval-expression
is so that it will use read-expression-map and
read-expression-history.  There is no clean way to make
(interactive "x") use them.

If this change causes trouble, we could create a new command with the
new meaning of pp-eval-expression, and document that for users; then
we could put pp-eval-expression back the old way, just for Lisp
callers.


*** pp.el	03 Nov 2006 09:45:00 -0500	1.30
--- pp.el	05 Jan 2007 18:29:41 -0500	
***************
*** 97,107 ****
    (princ (pp-to-string object) (or stream standard-output)))
  
  ;;;###autoload
! (defun pp-eval-expression (expval)
!   "Evaluate an expression, then pretty-print value EXPVAL into a new buffer.
! If pretty-printed EXPVAL fits on one line, display it in the echo
! area instead.  Also add EXPVAL to the front of the list
! in the variable `values'.
  
  Non-interactively, the argument is the value, EXPVAL, not the expression
  to evaluate."
--- 97,107 ----
    (princ (pp-to-string object) (or stream standard-output)))
  
  ;;;###autoload
! (defun pp-eval (expval)
!   "Pretty-print the value of an expression into a new buffer.
! If it fits on one line, display it in the echo area instead.
! Also add the value, EXPVAL, to the front of the list in the
! variable `values'.
  
  Non-interactively, the argument is the value, EXPVAL, not the expression
  to evaluate."
***************
*** 139,144 ****
--- 139,152 ----
  	(set (make-local-variable 'font-lock-verbose) nil)))))
  
  ;;;###autoload
+ (defun pp-eval-expression (expression)
+   "Evaluate EXPRESSION and pretty-print its value.
+ This function exists for compatibility with callers in Lisp code.
+ For interactive use, `pp-eval' should be more convenient."
+   (interactive "xPp-eval-expression: ")
+   (pp-eval (eval expression)))
+ 
+ ;;;###autoload
  (defun pp-eval-last-sexp (arg)
    "Run `pp-eval-expression' on sexp before point (which see).
  With argument, pretty-print output into current buffer.

RE: pp-eval-expression broken

[Drew Adams]

> The reason for the change in pp-eval-expression
> is so that it will use read-expression-map and
> read-expression-history.  There is no clean way to make
> (interactive "x") use them.
>
> If this change causes trouble, we could create a new command with the
> new meaning of pp-eval-expression, and document that for users; then
> we could put pp-eval-expression back the old way, just for Lisp
> callers.

It was I who suggested using `read-expression-history' and
`read-expression-map' (thread "pp-eval-expression should use
read-expression-history" in Emacs-Pretest-Bug, 2006-10-14).

That's what I do in my own redefined `pp-eval-expression'. But I don't use
(interactive "X") or (interactive "x"). I just use this:

(interactive
 (list (read-from-minibuffer "Eval: " nil read-expression-map t
                             'read-expression-history))

Is there a problem with using that?

I'm not necessarily suggesting the following changes, but I also:
1. inhibit `emacs-lisp-mode-hook'.
2. call `font-lock-fontify-buffer'.
3. add a progress message ("Evaluating...").

Here's the code, FWIW (updated today, to deal with the recent non-eval for
Emacs 22):

(defun pp-eval-expression (expression)
  "Evaluate EXPRESSION and pretty-print value into a new display buffer.
If the pretty-printed value fits on one line, the message line is used
instead.  The value is also consed onto the front of the list in the
variable `values'."
  (interactive
   (list (read-from-minibuffer
          "Eval: " nil read-expression-map t
          'read-expression-history)))
  (message "Evaluating...")
  (unless (or (interactive-p) (> emacs-major-version 21)) ; Emacs 22 fix.
    (setq expression (eval expression)))
  (setq values (cons expression values))
  (let* ((old-show-function temp-buffer-show-function)
	 ;; Use this function to display the buffer.
	 ;; This function either decides not to display it
         ;; at all or displays it in the usual way.
	 (temp-buffer-show-function
	  (function
	   (lambda (buf)
	     (save-excursion
	       (set-buffer buf)
	       (goto-char (point-min))
	       (end-of-line 1)
	       (if (or (< (1+ (point)) (point-max))
		       (>= (- (point) (point-min))
                           (frame-width)))
		   (let ((temp-buffer-show-function
                          old-show-function)
			 (old-selected (selected-window))
			 (window (display-buffer buf)))
		     (goto-char (point-min))
		     (make-frame-visible
                      (window-frame window))
		     (unwind-protect
			 (progn
			   (select-window window)
			   (run-hooks
                            'temp-buffer-show-hook))
		       (select-window old-selected)
                       (message
                        "Evaluating...done.  \
See buffer *Pp Eval Output*.")))
		 (message "%s"
                          (buffer-substring (point-min)
                                            (point)))))))))
    (with-output-to-temp-buffer "*Pp Eval Output*"
      (pp (car values)))
    (save-excursion
      (set-buffer "*Pp Eval Output*")
      (setq buffer-read-only nil)
      (let ((emacs-lisp-mode-hook nil)
            (change-major-mode-hook nil))
        (emacs-lisp-mode))
      (make-local-variable 'font-lock-verbose)
      (setq font-lock-verbose nil)
      (font-lock-fontify-buffer))))

RE: pp-eval-expression broken

[Drew Adams]

Oops. FWIW, my "fix" of my version of `pp-eval-expression' to deal with the
Emacs 22 code change was no good. Instead of this:

(unless (or (interactive-p) (> emacs-major-version 21))
  (setq expression (eval expression)))

it should have been this:

(unless (and (not (interactive-p)) (> emacs-major-version 21))
  (setq expression (eval expression)))

Re: pp-eval-expression broken

[Richard Stallman]

    That's what I do in my own redefined `pp-eval-expression'. But I don't use
    (interactive "X") or (interactive "x"). I just use this:

    (interactive
     (list (read-from-minibuffer "Eval: " nil read-expression-map t
				 'read-expression-history))

    Is there a problem with using that?

That seems ok.

RE: pp-eval-expression broken

[Drew Adams]

>     That's what I do in my own redefined `pp-eval-expression'.
>     But I don't use
>     (interactive "X") or (interactive "x"). I just use this:
>
>     (interactive
>      (list (read-from-minibuffer "Eval: " nil read-expression-map t
> 				 'read-expression-history))
>
>     Is there a problem with using that?
>
> That seems ok.

Does that mean that you will reverse the change to `pp-last-sexp' that evals
its arg before calling `pp-eval-expression', and let `pp-eval-expression'
always eval its arg? I hope so.

Otherwise, I see a problem in having the Lisp behavior of
`pp-eval-expression' (no evaluation of its argument) be different from its
interactive behavior (arg evaluation).

The problem is worse than I thought. I thought that I could get by with just
this tweak in my own definition of `pp-eval-expression':

  (interactive
   (list (read-from-minibuffer "Eval: " nil read-expression-map t
                               'read-expression-history)))
  (unless (and (not (interactive-p)) (> emacs-major-version 21))
    (setq expression (eval expression)))

However, although that works for Lisp functions, such as
`pp-eval-last-sexp', written with the new, Emacs-22 interface in mind, and
it works OK interactively, it fails for `repeat-complex-command' in Emacs
22, because that re-evaluates an interactive call as a Lisp sexp. It causes
`repeat-complex-command' following `pp-eval-expression' not to evaluate the
expression at all.

I really think the best approach is to return to the pre-Emacs 22 behavior
of `pp-eval-expression' always evaluating its argument and
`pp-eval-last-sexp' not evaluating the sexp before it passes it to
`pp-eval-expression'.

RE: pp-eval-expression broken

[Drew Adams]

> Does that mean that you will reverse the change to `pp-last-sexp'
> that evals its arg before calling `pp-eval-expression', and let
> `pp-eval-expression' always eval its arg? I hope so.

I see that you made the latter change. Thanks.

However, I think you also need to make the change to `pp-eval-last-sexp'.
Since `pp-eval-expression' evals its arg, `pp-eval-last-sexp' should not
pre-evaluate it; otherwise, it will be doubly eval'd.

Re: pp-eval-expression broken

[Richard Stallman]

Thanks.