GNU bug report logs - #76715
30.1; Issues when pretty printing lists with elements ending with a dot

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76715 in the body.
You can then email your comments to 76715 AT debbugs.gnu.org in the normal way.

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

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

From: pkryger <at> gmail.com
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; Issues when pretty printing lists with elements ending with a
 dot
Date: Mon, 03 Mar 2025 16:22:04 +0000

The defualt pretty printing function `pp-fill' yields different output than the expression to be printed. I managed to simplify the cases to the following:

(let ((pp-default-function #'pp-fill)
      (fill-column 8))
  (pp '(x. y. z.)))

yields output that is not the same expression as the input:

(x. y
    . z.)

When the `fill-column' is smaller (or there are more elements in input) the yielded value is not a valid s-expression

(let ((pp-default-function #'pp-fill)
      (fill-column 5))
  (pp '(x. y. z.)))

yields:

(x
 . y
 . z.)

Trying to `read' it back:
(read
 (let ((pp-default-function #'pp-fill)
       (fill-column 5))
   (pp '(x. y. z.))))

Yields the following error:

Debugger entered--Lisp error: (invalid-read-syntax "expected )")
  read("(x\n . y\n . z.)\n")
  (progn (read (let ((pp-default-function #'pp-fill) (fill-column 5)) (pp '(x. y. z.)))))
  eval((progn (read (let ((pp-default-function #'pp-fill) (fill-column 5)) (pp '(x. y. z.))))) t)
  elisp--eval-last-sexp(nil)
  #f(compiled-function () #<bytecode 0x518641632d4e2>)()
  handler-bind-1(#f(compiled-function () #<bytecode 0x518641632d4e2>) (error) eval-expression--debug)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

For comparison the `pp-29' yields correct output (it's `fill-column' insensitive, hence omitted in the example):

(let ((pp-default-function #'pp-29))
  (pp '(x. y. z.)))

yields (I guess) exepcted output:

(x. y. z.)

For a real life error, please see: https://github.com/purcell/package-lint/issues/285


In GNU Emacs 30.1 (build 1, aarch64-unknown-linux-gnu)
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure
 --prefix=/nix/store/whhfliclsxcxxjb43hd1csncqj6jf5aj-emacs-30-1
 --disable-build-details --with-modules --with-x=no --with-ns=no
 --with-xpm=no --with-jpeg=no --with-png=no --with-gif=no
 --with-tiff=no'

Configured features:
GMP GNUTLS LIBXML2 MODULES NOTIFY INOTIFY PDUMPER SECCOMP SOUND SQLITE3
THREADS TREE_SITTER

Important settings:
  locale-coding-system: nil

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dnd dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader smtpmail auth-source eieio eieio-core
password-cache json subr-x map sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cl-macs use-package-ensure cl-seq
use-package-core jka-compr noutline outline icons cl-extra shortdoc
text-property-search comp-common regexp-opt rx help-fns radix-tree
cl-print debug backtrace help-mode tool-bar find-func pp cl-loaddefs
cl-lib term/xterm xterm byte-opt gv bytecomp byte-compile disp-table rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads inotify multi-tty
make-network-process emacs)

Memory information:
((conses 16 117797 13078) (symbols 48 8010 0) (strings 32 21505 2148)
 (string-bytes 1 550215) (vectors 16 11636)
 (vector-slots 8 99179 8394) (floats 8 89 258) (intervals 56 1933 148)
 (buffers 992 15))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: pkryger <at> gmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76715 <at> debbugs.gnu.org
Subject: Re: bug#76715: 30.1;
 Issues when pretty printing lists with elements ending with a dot
Date: Tue, 04 Mar 2025 14:36:59 +0200

> From: pkryger <at> gmail.com
> Date: Mon, 03 Mar 2025 16:22:04 +0000
> 
> 
> The defualt pretty printing function `pp-fill' yields different output than the expression to be printed. I managed to simplify the cases to the following:
> 
> (let ((pp-default-function #'pp-fill)
>       (fill-column 8))
>   (pp '(x. y. z.)))
> 
> yields output that is not the same expression as the input:
> 
> (x. y
>     . z.)
> 
> When the `fill-column' is smaller (or there are more elements in input) the yielded value is not a valid s-expression
> 
> (let ((pp-default-function #'pp-fill)
>       (fill-column 5))
>   (pp '(x. y. z.)))
> 
> yields:
> 
> (x
>  . y
>  . z.)
> 
> Trying to `read' it back:
> (read
>  (let ((pp-default-function #'pp-fill)
>        (fill-column 5))
>    (pp '(x. y. z.))))
> 
> Yields the following error:
> 
> Debugger entered--Lisp error: (invalid-read-syntax "expected )")
>   read("(x\n . y\n . z.)\n")
>   (progn (read (let ((pp-default-function #'pp-fill) (fill-column 5)) (pp '(x. y. z.)))))
>   eval((progn (read (let ((pp-default-function #'pp-fill) (fill-column 5)) (pp '(x. y. z.))))) t)
>   elisp--eval-last-sexp(nil)
>   #f(compiled-function () #<bytecode 0x518641632d4e2>)()
>   handler-bind-1(#f(compiled-function () #<bytecode 0x518641632d4e2>) (error) eval-expression--debug)
>   eval-last-sexp(nil)
>   funcall-interactively(eval-last-sexp nil)
>   call-interactively(eval-last-sexp nil nil)
>   command-execute(eval-last-sexp)
> 
> For comparison the `pp-29' yields correct output (it's `fill-column' insensitive, hence omitted in the example):
> 
> (let ((pp-default-function #'pp-29))
>   (pp '(x. y. z.)))
> 
> yields (I guess) exepcted output:
> 
> (x. y. z.)
> 
> For a real life error, please see: https://github.com/purcell/package-lint/issues/285

Stefan, any comments or suggestions?

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pkryger <at> gmail.com, 76715 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#76715: 30.1; Issues when pretty printing lists with
 elements ending with a dot
Date: Wed, 05 Mar 2025 14:37:51 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Stefan, any comments or suggestions?

It's a regression from 2024, related to

  7269a2f1586 "(pp-fill): Cut before parens and dots"

So we must ensure that the dots where we cut are not part of a symbol.


Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pkryger <at> gmail.com, 76715-done <at> debbugs.gnu.org
Subject: Re: bug#76715: 30.1; Issues when pretty printing lists with
 elements ending with a dot
Date: Wed, 05 Mar 2025 18:35:52 -0500

>> The defualt pretty printing function `pp-fill' yields different
>> output than the expression to be printed. I managed to simplify the
>> cases to the following:
>> 
>> (let ((pp-default-function #'pp-fill)
>>       (fill-column 8))
>>   (pp '(x. y. z.)))
>> 
>> yields output that is not the same expression as the input:
>> 
>> (x. y
>>     . z.)

I pushed the patch below to `master`.  That should fix this problem.


        Stefan


diff --git a/lisp/emacs-lisp/pp.el b/lisp/emacs-lisp/pp.el
index 3e75807f757..c183f442d8d 100644
--- a/lisp/emacs-lisp/pp.el
+++ b/lisp/emacs-lisp/pp.el
@@ -208,7 +208,14 @@ pp-fill
                       (while
                           (progn
                             (funcall avoid-unbreakable)
-                            (not (zerop (skip-chars-backward " \t({[',.")))))
+                            (let ((pos (point)))
+                              (skip-chars-backward " \t({[',.")
+                              (while (and (memq (char-after) '(?\. ?\{))
+                                          (not (memq (char-before)
+                                                     '(nil ?\n ?\) \" ?\]))))
+                                ;; `.' and `{' within symbols?  (Bug#76715)
+                                (forward-char 1))
+                              (not (eql pos (point))))))
                       (if (bolp)
                           ;; The sexp already starts on its own line.
                           (progn (goto-char beg) nil)

Previous Next

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