bug#19362: 25.0.50; Fix `pp.el' in line with new `elisp-mode.el'

[Noam Postavsky <npostavs@users.sourceforge.net>]

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.