From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 19362@debbugs.gnu.org
Subject: bug#19362: 25.0.50; Fix `pp.el' in line with new `elisp-mode.el'
Date: Wed, 6 Jul 2016 23:51:47 +0000 (UTC) [thread overview]
Message-ID: <126bba1e-3f86-4ae3-b7b5-59532f62e4f6@default> (raw)
In-Reply-To: <CAM-tV-_2Wgxq8-14zbJyST5kva0nZEAMe7hPBNC6NxNa6AXd=Q@mail.gmail.com>
> > 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.
Sorry, but I have no more time to devote to this. I pointed to a
time where the code was more or less the same between the two, and
to a time where it had been changed to be really quite different.
It seemed (and still seems) clear to me that the non-pp version was
altered considerably - probably improving something, or adapting to
some other change (lexical binding, perhaps?), and the pp version
was not altered similarly. My guess is that the pp version was
considered less important or was simply overlooked/ignored.
I think it deserves a similar look. If no one wants to do that,
so be it.
If you feel you've taken a careful look and understand what changed
and why, and that none of the changes can be usefully extended to
pp, fine. I'm not looking at this anymore, so you'll get no argument
from me. I think I've said all I want to say about this. Thanks for
having taken a look.
next prev parent reply other threads:[~2016-07-06 23:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-13 2:46 bug#19362: 25.0.50; Fix `pp.el' in line with new `elisp-mode.el' Drew Adams
2016-04-30 16:26 ` Lars Ingebrigtsen
2016-04-30 17:36 ` Drew Adams
2016-04-30 17:43 ` Lars Ingebrigtsen
2016-04-30 18:16 ` Drew Adams
2016-04-30 18:33 ` Lars Ingebrigtsen
2016-07-01 2:04 ` npostavs
2016-07-01 3:07 ` Drew Adams
2016-07-06 20:39 ` Noam Postavsky
2016-07-06 22:35 ` Drew Adams
2016-07-06 23:36 ` Noam Postavsky
2016-07-06 23:51 ` Drew Adams [this message]
2016-07-07 0:26 ` npostavs
2016-07-07 2:34 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=126bba1e-3f86-4ae3-b7b5-59532f62e4f6@default \
--to=drew.adams@oracle.com \
--cc=19362@debbugs.gnu.org \
--cc=larsi@gnus.org \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.