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

Previous Next

Full log

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

From: Tom Gillespie <tgbugs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 55645 <at> debbugs.gnu.org
Subject: Re: bug#55645: src/print.c; print_object changes make it impossible
 to compare elisp code across versions
Date: Thu, 14 Jul 2022 14:36:08 -0700

> Like I've said before, we (the Emacs maintainers) would not guarantee
> that Emacs' `prin1' will remain the same.  If you want to create a
> package that does printing in a different way, you're free to do so, of
> course -- we have the `cl-prin1' framework in Emacs already, and you can
> use that to print things any way you want

Unfortunately none of these work for my use case because cl-prin1
is not available before emacs 26 and it differs too much from prin1
to be useful without requiring additional code. I have to fit all the code
under 3000 chars because it is in an eval local variable and the changes
for cl-prin1 are too extensive.

I'm not 100% sure how to use cl-prin1 but as far as I can tell defining
new cl-print-object methods (e.g. for symbol) is highly invasive and
makes changes to the entirety of the user's runtime.

Would a patch that leveraged cl-prin1 to create a function that matches
the old behavior of prin1 be more viable?

Without that my only solution is to restrict symbol names so that they
do not include . and ? by raising an error if they are detected, and hoping
that prin1 doesn't undergo another change in the future in the readable
subset of objects.

Previous Next

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