[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19362: 25.0.50; Fix `pp.el' in line with new `elisp-mode.el'
From: |
Noam Postavsky |
Subject: |
bug#19362: 25.0.50; Fix `pp.el' in line with new `elisp-mode.el' |
Date: |
Wed, 6 Jul 2016 19:36:55 -0400 |
On Wed, Jul 6, 2016 at 6:35 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> But do you know of any concrete cases where there is a difference in
>> behaviour? Or is this report just about code duplication (or lack
>> thereof)?
>
> 1. I don't know about concrete cases; sorry.
>
> 2. This report is an enhancement request; it doesn't report a bug.
>
> In the past, `eval-last-sexp' and `pp-eval-last-sexp' did about the
> same thing, apart from the pretty-printing part (which the latter
> farms out to another function).
So you're not talking about the difference between pp-to-string vs
elisp--eval-last-sexp-print-value.
> My guess is that _improvements_
> were made to the former case (only). Just what those improvements
> were and why they were made I don't know.
[...]
> In any case, I was not really referring to the interactive behavior
> but to the code/behavior after the sexp has been determined. In
> the case of `eval-last-sexp' I guess that means the code other
> than `elisp--preceding-sexp'.
And you're not talking about the difference between (pp-last-sexp) vs
(eval-sexp-add-defvars (elisp--preceding-sexp)).
What's left? They both call eval in the middle. eval-last-sexp honours
eval-expression-debug-on-error while pp-eval-last-sexp does not (this
was the case for the old lisp-mode.el code in 24.3 as well). Other
than that I don't see anything of significance.