emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recent keyboard changes breaks quitting


From: Chong Yidong
Subject: Re: Recent keyboard changes breaks quitting
Date: Sun, 23 Sep 2012 14:05:40 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Nope.  Turning off font-lock mode does, but I think this is only because
>> font-lock is is the only thing in my Emacs running an idle timer, in
>> this case jit-lock-context-fontify.  If I add any idle timer manually
>> (unrelated to font-lock), the same quitting problem appears.
>
> Hmm... so what idle timer runs when blink-cursor-mode is disabled?

I just told you: jit-lock-context-fontify.

But it's not a misbehaving idle timer, if that's what you're wondering
about.  It is possible to reproduce the bug when *any* idle timer is
around, e.g. putting this in the init file

  (global-font-lock-mode 0)
  (defun foo-timer-fun (&rest ignored)
    (message "%d" foo))

and running

  M-: (run-with-idle-timer 2 nil #'foo-timer-fun) RET
  M-x C-g

My attempts at tracing indicate that your timer_check change causes
significant changes in wait_reading_process_output's order of execution
when there is an idle timer present.  I think the problem occurs in the
call in process.c:110145, with

wait_reading_process_output
  -> detect_input_pending_run_timers
    -> get_input_pending
      -> readable_events
        -> timer_check

This timer_check does not call process_pending_signals.  Now, the same
call to timer_check does call process_pending_signals, apparently via
the QUIT macro.  Not sure if this helps.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]