GNU bug report logs - #78810
30.1; `pp' expectation of `emacs-lisp-mode-syntax-table' etc.

Previous Next

To reply to this bug, email your comments to 78810 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 30.1; `pp' expectation of `emacs-lisp-mode-syntax-table' etc.
Date: Tue, 17 Jun 2025 00:29:22 +0000

`pp' was redefined in Emacs 30.1, introducing quite a few changes in
behavior, including the _default_ behavior.  As the function is a basic
workhorse, these behavior changes can be widespread.

The new definition:

(defun pp (object &optional stream)
  "..."
  (cond
   ((and (eq (or stream standard-output) (current-buffer))
         ;; Make sure the current buffer is setup sanely.
         (eq (syntax-table) emacs-lisp-mode-syntax-table)
         (eq indent-line-function #'lisp-indent-line))
    ;; Skip the buffer->string->buffer middle man.
    (funcall pp-default-function object)
    ;; Preserve old behavior of (usually) finishing with a newline.
    (unless (bolp) (insert "\n")))
   (t
    (princ (pp-to-string object) (or stream standard-output)))))

The old definition wass just that `cond' else clause:

  (princ (pp-to-string object) (or stream standard-output))

Is the first `cond' clause "sanity" check really a good one for use by
`pp-default-function' - sufficient and necessary?  I wonder...

For one thing, the option value can be _any_ function.  The _doc_ says
the function should accept 0 or 1 arg and that it "can presume that the
buffer is setup for Lisp syntax."  But the defcustom code doesn't
support/ensure either of those things.

For another thing, that check for a "sane" buffer setup precludes using
`pp-default-function' with a buffer whose syntax table isn't exactly
`emacs-lisp-mode-syntax-table', which means it can't be used for buffers
in `lisp-data-mode'.  Is that really TRT?  Is there some reason not to
use `pp-default-function' with that mode's syntax table?

And why the `indent-line-function' requirement?  Does `pp's use of
`pp-default-function' really need its value to be `lisp-indent-line'?
That seems fragile - or else unncessary.

If these constraints are necessary for option `pp-default-function',
then its doc had really better proclaim them as such, no?  The doc (if
not the defcustom code itself) had better tell users that the function
can only be used in a buffer with that syntax table and with that value
of `indent-line-function'.

I can imagine existing pre-30.1 code ending up (after some debugging)
changing some `pp' calls to (insert (pp-to-string...)), to fix problems
created by this `pp' redefinition.  Or as `bookmark.el' did, to bind
`pp-default-function' to `pp-28' around `pp' calls.

And why is the option called `pp-default-function'?  It's a user option,
and it's used unconditionally - not to provide some function by
_default_.  It should be called `pp-printer-function' or `pp-function'
or some such.  (The FIXME comment refers to it as a "pretty printer"
function.)

My sense is that the 30.1 changes to `pp' were misguided (especially
changing the _default_ behavior).  Call me bad for saying that's what I
smell.  I hope I'm very wrong.


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

Message #8 received at 78810 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78810 <at> debbugs.gnu.org
Subject: Re: bug#78810: 30.1;
 `pp' expectation of `emacs-lisp-mode-syntax-table' etc.
Date: Tue, 17 Jun 2025 14:38:54 +0300

> Date: Tue, 17 Jun 2025 00:29:22 +0000
> From:  Drew Adams via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> `pp' was redefined in Emacs 30.1, introducing quite a few changes in
> behavior, including the _default_ behavior.  As the function is a basic
> workhorse, these behavior changes can be widespread.
> 
> The new definition:
> 
> (defun pp (object &optional stream)
>   "..."
>   (cond
>    ((and (eq (or stream standard-output) (current-buffer))
>          ;; Make sure the current buffer is setup sanely.
>          (eq (syntax-table) emacs-lisp-mode-syntax-table)
>          (eq indent-line-function #'lisp-indent-line))
>     ;; Skip the buffer->string->buffer middle man.
>     (funcall pp-default-function object)
>     ;; Preserve old behavior of (usually) finishing with a newline.
>     (unless (bolp) (insert "\n")))
>    (t
>     (princ (pp-to-string object) (or stream standard-output)))))
> 
> The old definition wass just that `cond' else clause:
> 
>   (princ (pp-to-string object) (or stream standard-output))
> 
> Is the first `cond' clause "sanity" check really a good one for use by
> `pp-default-function' - sufficient and necessary?  I wonder...
> 
> For one thing, the option value can be _any_ function.  The _doc_ says
> the function should accept 0 or 1 arg and that it "can presume that the
> buffer is setup for Lisp syntax."  But the defcustom code doesn't
> support/ensure either of those things.
> 
> For another thing, that check for a "sane" buffer setup precludes using
> `pp-default-function' with a buffer whose syntax table isn't exactly
> `emacs-lisp-mode-syntax-table', which means it can't be used for buffers
> in `lisp-data-mode'.  Is that really TRT?  Is there some reason not to
> use `pp-default-function' with that mode's syntax table?
> 
> And why the `indent-line-function' requirement?  Does `pp's use of
> `pp-default-function' really need its value to be `lisp-indent-line'?
> That seems fragile - or else unncessary.
> 
> If these constraints are necessary for option `pp-default-function',
> then its doc had really better proclaim them as such, no?  The doc (if
> not the defcustom code itself) had better tell users that the function
> can only be used in a buffer with that syntax table and with that value
> of `indent-line-function'.
> 
> I can imagine existing pre-30.1 code ending up (after some debugging)
> changing some `pp' calls to (insert (pp-to-string...)), to fix problems
> created by this `pp' redefinition.  Or as `bookmark.el' did, to bind
> `pp-default-function' to `pp-28' around `pp' calls.
> 
> And why is the option called `pp-default-function'?  It's a user option,
> and it's used unconditionally - not to provide some function by
> _default_.  It should be called `pp-printer-function' or `pp-function'
> or some such.  (The FIXME comment refers to it as a "pretty printer"
> function.)
> 
> My sense is that the 30.1 changes to `pp' were misguided (especially
> changing the _default_ behavior).  Call me bad for saying that's what I
> smell.  I hope I'm very wrong.

Stefan, any comments?

Message #11 received at 78810 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78810 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#78810: 30.1; `pp' expectation of
 `emacs-lisp-mode-syntax-table' etc.
Date: Tue, 17 Jun 2025 11:52:29 -0400

>> `pp' was redefined in Emacs 30.1, introducing quite a few changes in
>> behavior, including the _default_ behavior.  As the function is a basic
>> workhorse, these behavior changes can be widespread.
>> 
>> The new definition:
>> 
>> (defun pp (object &optional stream)
>>   "..."
>>   (cond
>>    ((and (eq (or stream standard-output) (current-buffer))
>>          ;; Make sure the current buffer is setup sanely.
>>          (eq (syntax-table) emacs-lisp-mode-syntax-table)
>>          (eq indent-line-function #'lisp-indent-line))
>>     ;; Skip the buffer->string->buffer middle man.
>>     (funcall pp-default-function object)
>>     ;; Preserve old behavior of (usually) finishing with a newline.
>>     (unless (bolp) (insert "\n")))
>>    (t
>>     (princ (pp-to-string object) (or stream standard-output)))))
>> 
>> The old definition wass just that `cond' else clause:
>> 
>>   (princ (pp-to-string object) (or stream standard-output))
>> 
>> Is the first `cond' clause "sanity" check really a good one for use by
>> `pp-default-function' - sufficient and necessary?  I wonder...
>> 
>> For one thing, the option value can be _any_ function.  The _doc_ says
>> the function should accept 0 or 1 arg and that it "can presume that the
>> buffer is setup for Lisp syntax."  But the defcustom code doesn't
>> support/ensure either of those things.
>> 
>> For another thing, that check for a "sane" buffer setup precludes using
>> `pp-default-function' with a buffer whose syntax table isn't exactly
>> `emacs-lisp-mode-syntax-table', which means it can't be used for buffers
>> in `lisp-data-mode'.  Is that really TRT?  Is there some reason not to
>> use `pp-default-function' with that mode's syntax table?
>> 
>> And why the `indent-line-function' requirement?  Does `pp's use of
>> `pp-default-function' really need its value to be `lisp-indent-line'?
>> That seems fragile - or else unncessary.
>> 
>> If these constraints are necessary for option `pp-default-function',
>> then its doc had really better proclaim them as such, no?  The doc (if
>> not the defcustom code itself) had better tell users that the function
>> can only be used in a buffer with that syntax table and with that value
>> of `indent-line-function'.
>> 
>> I can imagine existing pre-30.1 code ending up (after some debugging)
>> changing some `pp' calls to (insert (pp-to-string...)), to fix problems
>> created by this `pp' redefinition.  Or as `bookmark.el' did, to bind
>> `pp-default-function' to `pp-28' around `pp' calls.
>> 
>> And why is the option called `pp-default-function'?  It's a user option,
>> and it's used unconditionally - not to provide some function by
>> _default_.  It should be called `pp-printer-function' or `pp-function'
>> or some such.  (The FIXME comment refers to it as a "pretty printer"
>> function.)
>> 
>> My sense is that the 30.1 changes to `pp' were misguided (especially
>> changing the _default_ behavior).  Call me bad for saying that's what I
>> smell.  I hope I'm very wrong.
>
> Stefan, any comments?

Not, really, no, expect that I don't see any actual bug reported in that
long explanation and that Drew seems to miss the fact that the first
branch of the `cond` is basically an optimization.



        Stefan

Message #14 received at 78810 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "78810 <at> debbugs.gnu.org" <78810 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#78810: 30.1; `pp' expectation of
 `emacs-lisp-mode-syntax-table' etc.
Date: Tue, 17 Jun 2025 16:14:45 +0000

> > Stefan, any comments?
> 
> Not, really, no, expect that I don't see any actual bug reported in that
> long explanation and that Drew seems to miss the fact that the first
> branch of the `cond` is basically an optimization.

I didn't miss that the first `cond' branch was presumably
_intended_ to be only an optimization.  I don't think it
always has the same behavior (result) as the second branch,
and I do think it's bugged.  And the defcustom isn't solid,
and the doc and names are poor.

You don't respond to any of the questions.  For example, is
it necessary (or even desirable) for Elisp code in a buffer
with `lisp-data-mode' to use the second (unoptimized) `cond'
clause?  Is `lisp-indent-function' for `indent-line-function'
really needed (why)?  If so, tell users of the defcustom.

Message #17 received at 78810 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "78810 <at> debbugs.gnu.org" <78810 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#78810: 30.1; `pp' expectation of
 `emacs-lisp-mode-syntax-table' etc.
Date: Tue, 17 Jun 2025 16:02:13 -0400

> I didn't miss that the first `cond' branch was presumably
> _intended_ to be only an optimization.  I don't think it
> always has the same behavior (result) as the second branch,
> and I do think it's bugged.

I did get that impression but you don't show any evidence for it.

> And the defcustom isn't solid, and the doc and names are poor.

I don't know what "solid" means here.  w.r.t names, I'm not sure a new
name would be sufficiently better to justify the cost of renaming.

> You don't respond to any of the questions.

Didn't see any.  I guess they were too far drowned within lots of
other elements.

> For example, is it necessary (or even desirable) for Elisp code in
> a buffer with `lisp-data-mode' to use the second (unoptimized)
> `cond' clause?

I don't know.  Do you have any concrete data for or against it?

> Is `lisp-indent-function' for `indent-line-function'
> really needed (why)?

Does it matter?  Again, some concrete data would help.

> If so, tell users of the defcustom.

Why should they care?


        Stefan

Previous Next

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