GNU bug report logs - #54537
29.0.50; Last sexp notion is different for eval-last-sexp and pp-eval-last-sexp

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "54537 <at> debbugs.gnu.org" <54537 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#54537: 29.0.50; Last sexp notion is
 different for eval-last-sexp and pp-eval-last-sexp
Date: Wed, 23 Mar 2022 21:06:01 +0000

> > Whether it's better ("more convenient") or not,
> > I don't know.  But it's a backward-incompatible
> > change.  That might be one thing to consider -
> > what users expect will break/change.
> 
> Sure, but the current (inconsistent) behaviour is surprising.

Is it?  The `pp-*' commands have different uses.

FWIW, I even add separate variables for PP, for
controlling print level and length.  Force-using
the same values for the `pp-*' commands doesn't
make sense to me.

Similarly, I'm not shocked by the difference this
bug report wants to get rid of.  I don't necessarily
object to the change.  I'm just not convinced that
such consistency is important.

What matters most wrt consistency is _local_
consistency - being consistent within a given
context/scope/set of rules.  PP is a different
world (context).

(That's not an argument why PP's last-sexp should
be different.  It's an argument that just a "more
convenient" argument that it should be the same
isn't a strong one.)

> I would be personally okay with such a
> backwards-incompatible change, but I am
> biased since I filed the bug report.

It's a reasonable proposal to examine.  And it
might be the right thing to do.

My contribution is just to point out that PP eval
is not non-PP eval, and "more convenient" isn't a
strong argument when the increment of "more" isn't
large.  And when introducing backward-incompatible
behavior maybe other, stronger arguments would help.

Maybe bring this up on emacs-devel, to see if more
and better arguments for and against the change
are available?  (Not a requirement, of course.)

Previous Next

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