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

[Drew Adams]

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

> I found #10495 "pp-eval-last-sexp doesn't work on a `symbol' in
> quotes", but that was reported against 24.0.92, so perhaps these
> functions were in fact never "aligned"?

The functions used to be mostly "aligned", but it's possible that
the difference Michael points out in #10495 was present.  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'.  I'm interested in both, but I don't
think I was paying attention to differences that are covered by the
`elisp--preceding-sexp' code.

Michael's bug is all about extending what `elisp--preceding-sexp'
does to pp.el.  It could perhaps be a good start, in terms of
realignment.  On the other hand, that behavior seems to be overly
DWIM, making heuristic assumptions about what sexp you _really_
wanted to evaluate.  I'm not sure that's always such a good thing.
I'd probably rather have that DWIM be a user choice (option).
`pp-eval-last-sexp' is much simpler.

In any case, what `elisp--preceding-sexp' is/does is not really
what I had in mind about the code divergence, as you rightfully
observed.  So I guess this bug report is somewhat complementary
to Michael's report.