unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).