GNU bug report logs - #55645
src/print.c; print_object changes make it impossible to compare elisp code across versions

Previous Next

Full log

View this message in rfc822 format

From: Tom Gillespie <tgbugs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55645 <at> debbugs.gnu.org
Subject: bug#55645: src/print.c; print_object changes make it impossible to compare elisp code across versions
Date: Fri, 27 May 2022 12:19:27 -0700

> but admittedly, these changes are usually for more obscure
> objects than symbols

I was thinking the same. I realize that for many objects where
there is no guarantee of homoiconicity the prin1 representation
definitely changes all the time. However, I think that symbols
fall into a more homoiconic category (namely the category
of objects that can appear literally in code).

Some time between emacs 18 and xemacs/22 the reader
DID change with regard to periods in symbols. In 18 you had
to escape the period or the reader throws a syntax error.

Thus your point about there being a mismatch between read
behavior and prin1 representation is accurate.

That being said, I think this is be the first time in the history
of emacs that prin1 for symbols has changed, so having a
way to preserve the old behavior for things that depend on it
would be greatly appreciated.

> prin1?  Stable for 30 years?  Nope.  (But some objects have had a stable
> printed representation that long, I'm sure.)

Er, indeed, I was being overly general, I meant symbols specifically.
I went back and checked in emacs-18 and this is what I get:

(prin1-to-string '(a b\.c d))
"(a b\\.c d)"
(emacs-version)
"GNU Emacs 18.59.1 of Sat Jul 31 2021 on localhost (linux)"

Previous Next

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