bug#54537: Re: bug#54537: 29.0.50; Last sexp notion is different for eval-last-sexp and pp-eval-last-sexp

[Drew Adams]

> `(,(+ 2 3)
>   ,(+ 4 5))
> 
> The non-pp behavior is useful (you are able to eval the inserted
> subexpressions).  The pp behavior is not useful (error).

OK, I'm convinced.  I didn't (and I don't) see a good
reason for the `pp-*' behavior is that regard.  Just
wanted people to take a look.

What's needed is a fixed version of `pp-last-sexp'.
It's not about `pp-eval-last-sexp'.

pp-last-sexp' has several differences from
`elisp--preceding-sexp'.  Should some of those
differences be kept?  Dunno.  E.g.,  it uses `read',
and it ignores leading comments.

Regardless of what changes are made to `pp-last-sexp',
I think those changes should allow the functions that
call `pp-last-sexp' to remain unchanged; IOW, fix
`pp-last-sexp', but don't change how it's used/called.

E.g., `pp-eval-last-sexp' should remain with this code:

(defun pp-eval-last-sexp (arg)
  "..."
  (interactive "P")
  (if arg
      (insert (pp-to-string (eval (pp-last-sexp)
                                  lexical-binding)))
    (pp-eval-expression (pp-last-sexp))))

Similarly `pp-macroexpand-last-sexp'.  There's no doubt
other code out there (I have some) that makes use of
`pp-last-sexp'.  Let's please have just a simple fix of
`pp-last-sexp'.

And besides allowing no changes in calling, preferably
no other behavior would be changed than to fix this bug.