Re: Why is `after-change-functions' reset?

[Kalle Olavi Niemitalo]

Michael Heerdegen <address@hidden> writes:

> Evaluate it and hit tab (for completion) and C-g C-g in succession.
> When you repeat this a few times, you get "Why does this happen?".

I debugged this a bit, with my custom Emacs 23.0.51.  I don't
know how much this machinery has changed in later versions.
Emacs set Vquit_flag at:

  handle_interrupt
  tty_read_avail_input
  read_avail_input
  handle_async_input
  input_available_signal
  <signal handler called>
  mark_object
  Fgarbage_collect
  Ffuncall
  run_hook_list_with_args
  signal_after_change
  Fadd_text_properties
  Fput_text_property
  Fdisplay_completion_list
  internal_with_output_to_temp_buffer
  Fminibuffer_completion_help
  do_completion
  Fminibuffer_complete
  Ffuncall
  Fcall_interactively

After Fgarbage_collect returned, Ffuncall called funcall_lambda,
in which the QUIT macro detected the non-nil value of Vquit_flag
and called Fsignal (Qquit, Qnil).  Because the quit was signaled
within signal_after_change, after-change-functions were not
restored.

I don't see any reasonable way to prevent after-change-functions
from being reset like this.

> In my original situation, quitting was not involved, the above
> recipe was just the first reproducible program I had discovered.

Perhaps you could change your Emacs to break when the reset
happens, and always run it in a debugger.  Make
signal_before_change and signal_after_change maintain some kind
of flag or nesting counter, and set conditional breakpoints in
Fthrow and Fsignal.  That will get a false positive if the error
is caught within the hook; but I don't think it happens often.