OK, I skimmed through the trail on 29220 and it appears to me as though there was no definitive fix implemented - even though there was an acknowledgment that a problem existed. The annotation at the end indicates there have been no changes for 268 days, so I guess that is it. My object instances are definitely complicated and probably do have circularities.

I think perhaps you might want to put more information/warnings in section 19 of the Elisp manual because it is obviously not true anymore that you can simply Print/Read any arbitrary Lisp Object.

I'm going to trap the error in my extension and just force reading/"compiling" from the original text file instead of reading from the intermediate file created by the print process. This will just cause a small delay to the user the first time that a set of language templates get loaded in an edit session - probably not a big deal. Certainly, it is better than telling people my extension is "broken" and won't work with 26.1 and onwards.

Thanks for the help and information.

Regards
Peter

On Wed, Nov 21, 2018 at 8:19 AM Noam Postavsky <npostavs@gmail.com> wrote:
On Tue, 20 Nov 2018 at 16:09, Peter Milliken <peter.milliken@gmail.com> wrote:
>
> Not sure what the reference to circular structures means in this context. As I said, all versions of Emacs less than 26 it worked fine with these same Lisp Objects.
>
> As I said: what changed?  Are you trying to say something in 26.1 is now "fixed" i.e. it should never have worked in versions less than 26? and what I have been doing for years should have always failed?

I think the difference is that in Emacs 25 and earlier the type of a
struct (or eieio class?) was encoded as a symbol, whereas in Emacs 26
and later it is a record object with circular references.

See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#47 and replies.