[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undo-auto--undoable-change infloop
From: |
Eli Zaretskii |
Subject: |
Re: undo-auto--undoable-change infloop |
Date: |
Sat, 30 Jul 2022 08:54:20 +0300 |
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Sat, 30 Jul 2022 03:14:18 +0200
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > Maybe this is a symptom of having way too many timers?
>
> Maybe.
>
> Could it be that when executing the timer function takes longer than the
> 0.1 seconds repeat delta, the timer fires again?
See timer-event-handler, which is the function invoked when a timer is
ripe, and handles both the invocation of the timer function and
rescheduling of the next timer invocation. My reading of it is that
the above _could_ happen, but:
. it can only happen if the timer function calls something that
causes Emacs to wait for input, like sit-for, perhaps or
accept-process-output, because otherwise Emacs will not check for
ripe timers for as long as the timer function runs
. the number of such "overlapping" invocations should not be more
than 10, controlled by the value of timer-max-repeats
- Re: No, not solved, (continued)
- Re: No, not solved (was: undo-auto--undoable-change infloop), Eli Zaretskii, 2022/07/29
- Re: undo-auto--undoable-change infloop, Eli Zaretskii, 2022/07/27
- Re: undo-auto--undoable-change infloop, Michael Heerdegen, 2022/07/27
- Re: undo-auto--undoable-change infloop, Eli Zaretskii, 2022/07/27
- Re: undo-auto--undoable-change infloop, Michael Heerdegen, 2022/07/27
- Re: undo-auto--undoable-change infloop, Stefan Monnier, 2022/07/29
- Re: undo-auto--undoable-change infloop, Michael Heerdegen, 2022/07/29
- Re: undo-auto--undoable-change infloop, Michael Heerdegen, 2022/07/30
- Re: undo-auto--undoable-change infloop,
Eli Zaretskii <=
- Re: undo-auto--undoable-change infloop, Stefan Monnier, 2022/07/30
- Re: undo-auto--undoable-change infloop, Michael Heerdegen, 2022/07/31