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

Previous Next

Full log

Message #34 received at 19362 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 19362 <at> debbugs.gnu.org
Subject: RE: bug#19362: 25.0.50; Fix `pp.el' in line with new `elisp-mode.el'
Date: Wed, 6 Jul 2016 22:35:49 +0000 (UTC)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.