Subject: bug#24469: undo-tree and ... when printing objects

From: Fabrice Popineau <[email-masked]>
Date: Mon, 19 Sep 2016 20:40:06 +0200

2016-09-19 15:57 GMT+02:00 Noam Postavsky <[email-masked]>:

> On Mon, Sep 19, 2016 at 9:29 AM, Fabrice Popineau
> <[email-masked]> wrote:
> >
> > Recently, Emacs started to dump "..." in undo-tree savefiles.  For each
> > file which is opened under Emacs, the undo-tree mode automatically saves
> > the undo tree in a separate file and this undo tree is loaded back when
> > the file is reloaded. The problem is in the way objects are printed.
> > Obviously, no "..." string should appear in the undo-tree file and it
> > started
> > to happen only a few weeks ago.
> >
> > Thanks for any help / explanation on what's happening.
>
> It sounds like maybe `print-level' and/or `print-length' is bound to a
> non-nil value while the tree is being printed? Can you show an example
> of a problematic undo-tree file?
>

Here is what grep found for me :

/c/temp/.!drive_c!Home!Org!AlgoCS!code!priorityQueue.specif.~undo-tree~:[cl-struct-undo-tree
[nil ([nil ([nil ([nil ([nil ... ... nil ... 0 nil]) ((444 . 465) (t 22484
14555 0 0)) nil (22484 14590 286032 100000) 0 nil]) ((443 . 444)) nil
(22484 14554 987413 0) 0 nil]) ((423 . 443) (t 22031 59305 0 0)) nil (22484
14554 987413 0) 0 nil]) nil nil (22484 14554 987413 0) 0 nil] #1=[nil nil
((415 . 417)) nil (22484 14641 640006 0) 0 nil] 3892 21 nil]

Maybe the problem is in undo-tree because the package binds print-circle to
t before printing its object, and it does not bind print-level and
print-lenght.
However, in my session, both print-level and print-length are nil. So I
wonder why suddenly, they should change when undo-tree does its job.

I'll try to trace the problem.

Fabrice