unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Toby Cubitt <tsc25@cantab.net>
Cc: 24640@debbugs.gnu.org, phillip.lord@russet.org.uk, rrt@sc3d.org
Subject: bug#24640: Crashes in 25.1
Date: Wed, 12 Oct 2016 20:28:47 +0300	[thread overview]
Message-ID: <83k2dda33k.fsf@gnu.org> (raw)
In-Reply-To: <20161012165656.GA19297@marvin.cs.ucl.ac.uk> (message from Toby Cubitt on Wed, 12 Oct 2016 17:56:56 +0100)

> 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.





  reply	other threads:[~2016-10-12 17:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-07 23:12 bug#24640: Crashes in 25.1 Reuben Thomas
2016-10-08  5:53 ` Eli Zaretskii
2016-10-08 13:28   ` Reuben Thomas
2016-10-08 13:30   ` Reuben Thomas
2016-10-08 14:30     ` Eli Zaretskii
2016-10-08 15:26       ` Reuben Thomas
2016-10-08 15:34         ` Eli Zaretskii
2016-10-08 22:08           ` Reuben Thomas
2016-10-09  7:05             ` Eli Zaretskii
2016-10-09  7:45               ` Reuben Thomas
2016-10-09  9:57                 ` Eli Zaretskii
2016-10-09 20:21                   ` Reuben Thomas
2016-10-10  6:15                     ` Eli Zaretskii
2016-10-10 16:12                       ` Reuben Thomas
2016-10-10 16:33                         ` Eli Zaretskii
2016-10-10 17:01                           ` Reuben Thomas
2016-10-10 17:05                             ` Eli Zaretskii
2016-10-10 17:06                               ` Reuben Thomas
     [not found]                           ` <CAOnWdoheXTvdasXN8vQFZPyayZVHD-QweqJupVrS8BQFxj2iGw@mail.gmail.com>
     [not found]                             ` <831szodsus.fsf@gnu.org>
     [not found]                               ` <CAOnWdojJHhajbRcinnubLfwWhY=snydnPM7Cws9ktX+pJe8aGA@mail.gmail.com>
     [not found]                                 ` <83zimccbzr.fsf@gnu.org>
     [not found]                                   ` <CAOnWdojzYsTR=wyrn-k2dJbStej89neskr=vwZQQWrQVCGtpkA@mail.gmail.com>
2016-10-11 11:59                                     ` Eli Zaretskii
2016-10-11 14:08                                       ` Reuben Thomas
2016-10-11 14:53                                         ` Eli Zaretskii
2016-10-11 15:19                                           ` Eli Zaretskii
2016-10-11 15:42                                             ` Reuben Thomas
2016-10-11 16:26                                               ` Eli Zaretskii
2016-10-11 15:41                                           ` Reuben Thomas
2016-10-11 16:33                                             ` Eli Zaretskii
2016-10-11 16:41                                               ` Reuben Thomas
2016-10-12 10:31                                               ` Eli Zaretskii
2016-10-12 10:57                                                 ` Reuben Thomas
2016-10-12 11:14                                                   ` Eli Zaretskii
2016-10-12 13:50                                                 ` Toby Cubitt
2016-10-12 14:44                                                   ` Eli Zaretskii
2016-10-12 16:56                                                     ` Toby Cubitt
2016-10-12 17:28                                                       ` Eli Zaretskii [this message]
2016-10-12 18:07                                                         ` Toby Cubitt
2016-10-12 19:15                                                           ` Eli Zaretskii
2016-10-12 20:45                                                             ` Reuben Thomas
2016-10-14 20:06                                                               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83k2dda33k.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=24640@debbugs.gnu.org \
    --cc=phillip.lord@russet.org.uk \
    --cc=rrt@sc3d.org \
    --cc=tsc25@cantab.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).