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