GNU bug report logs - #78801
30.1; `pp.el' changes for v30

Previous Next

Full log

Message #10 received at 78801-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 78801-done <at> debbugs.gnu.org
Subject: Re: bug#78801: 30.1; `pp.el' changes for v30
Date: Mon, 16 Jun 2025 10:17:54 +0300

> Date: Sun, 15 Jun 2025 17:08:59 +0000
> From:  Drew Adams via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> The bug name is maybe too general.  I'm still discovering more messes
> based on changes to `pp.el' for v30.1.
> 
> You added `pp-use-max-width' in v29.  And now you're obsoleting it in
> v30.1?  Not a good smell...

Please drop the attitude, it doesn't add motivation to read and handle
your bug reports.  When you report real problems with documentation
and code, they are taken and handled seriously even without
denigrating epithets and downright disdain for development decisions
where we dared -- quelle horreur! -- to disagree with your ideas.

> A specific (but multifarious) bug to report is this -
> 
> The defcustom for `pp-default-function' (new in 30.1) has this :tag,
> which is what users see in the Customize menu:
> 
>   "`pp-emacs-lisp-code' if `pp-use-max-width' else `pp-28'"
> 
> That's odd enough.  Unhelpful, as it means users need to look up three
> function definitions, just to grok what that menu item might mean.

Thanks, I fixed that tag.  I also fixed others, which were not clear
enough IMO.

> Worse still: It refers to a variable, `pp-use-max-width', that you've
> deprecated in 30.1!  Hard to believe; one can't make this stuff up.
> You introduce a new option that depends for its understanding on
> something you tell users is no longer to be used.
> 
> So to understand that menu item, you need to look up 3 functions, and
> grok their differences (using the doc, if sufficient).  AND then you
> need to discover that one of those functions is deprecated, and you're
> told that the `CURRENT-NAME' for the function, that is, the function
> that should be used instead, is `pp-default-function'.
> 
> But then ... `pp-default-function' isn't even a function!  It's a
> variable.
> 
> What's more, the :tag (menu item) that you're trying to figure out is
> for exactly that same variable!!  Poor user - you're the snake who's
> just discovered it's swallowing its own tail.

This is completely uncalled-for and simply not useful.  Just showing
the tag makes it abundantly clear that it should be improved.

> No doubt there are more problems introduced in `pp.el' in 30.1.

Here's your attitude again: why "no doubt"?  If you have specific
issues to report, please do, but insinuations like the above are just
that, and will not have any useful effect, let alone improve Emacs.

> I
> stumbled onto this because plain old lovable workhorse function `pp'
> has been changed in a backward-incompatible way.  I have yet to figure
> out what all the other damage is.  But suffice it to say that even
> vanilla bookmark.el has been forced to do this: wrap its call to `pp'
> with (let ((pp-default-function #'pp-28)).
> 
> Sorry to say it, but this really smells like shoddy work.  Standard,
> longstanding `pp' behavior is now relegated to a function called
> `pp-28'.
> 
> You couldn't just keep `pp' as was, and add whatever bells & whistles
> you're convinced are an improvement as another function or an opt-in
> option?  Is Emacs now trying to "move fast and break things"?
> 
> `pp' is so basic.  This surgery is akin to redefining `cons' to do
> lazy consing _by default_.
> 
> I don't even know what to recommend that you do at this point, to
> clean up the damage done.  You've tried to "prettify" PP, but you've
> made it a whole lot uglier, it seems.  Should instead have added a
> prettified-pretty-print library to ELPA, as a substitute or add-on.
> Poor little `pp' didn't deserve this (well intentioned) trashing.

More bad-mouthing of the Emacs developers and the development process
in general.  Not useful and unbecoming.  Please stop.

I'm closing this bug, as the only problem it usefully reported is now
fixed on the emacs-30 release branch.

Previous Next

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