[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: pp-eval-expression broken
From: |
Drew Adams |
Subject: |
RE: pp-eval-expression broken |
Date: |
Tue, 9 Jan 2007 14:56:40 -0800 |
> 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'.