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

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, "54537 <at> debbugs.gnu.org" <54537 <at> debbugs.gnu.org>, Visuwesh <visuweshm <at> gmail.com>
Subject: bug#54537: Re: bug#54537: 29.0.50; Last sexp notion is different for eval-last-sexp and pp-eval-last-sexp
Date: Thu, 24 Mar 2022 03:22:04 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> Still calls out for a better argument than a vague
> opinion that such a change adding incompatibility
> would be "more convenient".  That's all.

Ok - let's become concrete now.

About what kinds of use cases are we a talking about?  Use cases like
this:

#+begin_src emacs-lisp
`(,(+ 2 3)
  ,(+ 4 5))
#+end_src

The non-pp behavior is useful (you are able to eval the inserted
subexpressions).  The pp behavior is not useful (error).

This behaves identically in both versions:

#+begin_src emacs-lisp
',(+ 4 5)
#+end_src

(you get the expected `,(+ 4 5)`.)

So we only talk about plain naked `unquote` expressions.

Do you see any concrete advantages of the pp-version behavior?  Or some
concrete hints that the pp version must be like this for more
consistency in the pp package?

OTOH, a concrete problem I see is that people avoid pp due to such things.
As far as I recall the history of the pp package, I don't expect much
logic behind the behavior.  Maybe it really just...sucks?

Michael.

Previous Next

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