bug#54537: Re: bug#54537: 29.0.50; Last sexp notion is different for eval-last-sexp and pp-eval-last-sexp

[Visuwesh]

[புதன், மார்ச் 23 2022] Drew Adams wrote:

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

They do, and I don't object to that.  But when I see pp-eval-last-sexp,
I think it would do the same thing as eval-last-sexp but pretty prints
the result in a separate buffer instead.  In this regard, which I think
is a reasonable interpretation, pp-eval-last-sexp is not inconsistent
and hence behaves in an unexpected manner.

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

I would agree with you if this change removed an ability to do a certain
thing in the name of consistency but here, it merely changes the
behaviour to something more convenient.  I see no point in bikeshedding
further however, so I will stop here.  The final decision will be up to
the maintainers.

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