Subject: bug#78801: closed (Re: bug#78801: 30.1; `pp.el' changes for v30)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 16 Jun 2025 07:19:02 +0000

Your bug report

#78801: 30.1; `pp.el' changes for v30

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
78801: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78801
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#78801: 30.1; `pp.el' changes for v30
From: Eli Zaretskii <[email-masked]>
To: Drew Adams <[email-masked]>
Cc: [email-masked]
Date: Mon, 16 Jun 2025 10:17:54 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> 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" <[email-masked]>
> 
> 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.

Subject: 30.1; `pp.el' changes for v30
From: Drew Adams <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sun, 15 Jun 2025 17:08:59 +0000
List-Id: <debbugs-submit.debbugs.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...

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.

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.

No doubt there are more problems introduced in `pp.el' in 30.1.  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.

In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows 10 Pro (v10.0.2009.26100.4061)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2
 prefix=/g/rel/install/emacs-30.1'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252