bug#24640: Crashes in 25.1

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 12 Oct 2016 17:56:56 +0100
> Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org
> From: Toby Cubitt <tsc25@cantab.net>
> 
> > Does restoring undo-tree history manipulates buffer-undo-list of any
> > buffers in any way?
> 
> No. It just reads a lisp structure from file into the buffer-undo-tree
> variable.

In that case, changes in Emacs undo internals are probably off the
hook.  Hmm... which leaves us with what other suspects?

> > > Since the timer can't run whilst undo-tree lisp code is running
> > 
> > It can run if during restoring the history, undo-tree calls sit-for, or
> > asks a question, or calls some other API that enters redisplay and/or
> > involves user input.
> 
> During history loading it doesn't access buffer-undo-list at all, so it
> shouldn't matter if the timer runs.
> 
> When undoing, everything that accesses or touches buffer-undo-list is
> encapsulated in the three functions I listed. None of these call sit-for,
> prompt for input, or display anything. As far as I understand it, they
> shouldn't be able to trigger redisplay at all (caveat I'm no redisplay
> expert - that's you!)

Well, one place where redisplay could be triggered is those messages
about failure to load history, like this one (which actually happens
during restoring Emacs sessions from Reuben's desktop file):

  Error reading undo-tree history from "/home/user/.emacs.d/undo-tree/.!home!user!Foo!Bar!baz!doc!yyy.tex.~undo-tree~"

(I obfuscated a few directory names here to protect Reuben's privacy.)

Each such message enters redisplay.

But again, the undo timer is not the culprit, so this is just for
completeness.

> I don't think the undo timer can trigger elsewhere during undo-tree
> undo. Even if it does somehow trigger outside those three functions, this
> shouldn't break anything. Depending on when it triggers, undo-tree will
> either pick up the extra undo boundary added to buffer-undo-list this
> time around, or next time you undo.

I originally asked that question because Reuben's setup arranges for
restoring the session lazily, which means buffers are restored from
their files by functions that run off the idle timer.  So I thought
about two timers stepping on each other's toes.  Again, that proved to
be a dead end, at least for now.

> Indeed. But even if it's not to blame here, I still ought double-check
> the above carefully to make sure the new undo timer doesn't interact with
> undo-tree in some subtle way I've overlooked.

That's prudent, of course.

Thanks.