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

From: Drew Adams <[email-masked]>
Date: Sun, 15 Jun 2025 17:08:59 +0000

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