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

[Fabrice Popineau]

2016-09-19 15:57 GMT+02:00 Noam Postavsky <npostavs@users.sourceforge.net>:

On Mon, Sep 19, 2016 at 9:29 AM, Fabrice Popineau
<fabrice.popineau@gmail.com> 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