From: "Jan D." <jan.h.d@swipnet.se>
Cc: juri@jurta.org, yamaoka@jpl.org, teirllm@dms.auburn.edu,
emacs-devel@gnu.org
Subject: Re: undo in loaddefs.el buffer
Date: Tue, 28 Dec 2004 14:16:46 +0100 [thread overview]
Message-ID: <41D15CBE.8060105@swipnet.se> (raw)
In-Reply-To: <E1Cj3Sh-0002DN-DL@fencepost.gnu.org>
Luc Teirlinck wrote:
>If, for instance, a timer is involved that runs once every five
>seconds, or even more frequently, then, after the quit, the timer will
>run again, make the undo entry even larger without adding an undo
>boundary and ask the question again. And again, until something
>creates an undo boundary. I do not _know_ whether something like this
>is happening in the situations described above, but until I committed
>a patch yesterday evening, the described behavior was exactly what would
>happen (with up to a five second delay) if you auto-reverted the
>Buffer Menu every five seconds.
>
>The popup menu could be explained by any intervening mouse click.
>
There is no timer, and there is no mouse click. Just C-g, no mouse
movement, or anything else.
Richard Stallman wrote:
> For the original case (quitting out of the undo question), that would be
> an improvement as you could continue to hit Ctrl-g until all questions
> are gone :-). It is a strange case. I have to hit Ctrl-g three times
> for the yes-or-no question in the minibuffer to be canceled, but then a
> yes-or-no dialog pops up.
>
>I don't follow. If you type C-g, that should quit the command that is
>asking the question, so it won't produce any more undo info and it
>won't ask any more questions.
>
>If something other than that happens for you, why does it happen?
>Is it a bug?
>
Here is what I found.
The first time the question to discard is asked, it is asked by kill-region:
#0 Fyes_or_no_p (prompt=141235155) at fns.c:3279
#1 0x081c238e in Ffuncall (nargs=2, args=0xbfffe150) at eval.c:2775
#2 0x081f6065 in Fbyte_code (bytestr=137004643, vector=137004684,
maxdepth=40) at bytecode.c:686
#3 0x081c2b84 in funcall_lambda (fun=137004612, nargs=1,
arg_vector=0xbfffe374) at eval.c:2962
#4 0x081c25ab in Ffuncall (nargs=2, args=0xbfffe370) at eval.c:2823
#5 0x081c1fc5 in call1 (fn=138840169, arg1=61097120) at eval.c:2569
#6 0x081a3a86 in truncate_undo_list (b=0x83931e0) at undo.c:379
#7 0x081a829e in Fgarbage_collect () at alloc.c:4687
#8 0x081f5cbc in Fbyte_code (bytestr=137012651, vector=137012724,
maxdepth=40) at bytecode.c:523
#9 0x081c15fa in Feval (form=137012637) at eval.c:2136
#10 0x081c00b7 in Fcondition_case (args=140356805) at eval.c:1332
#11 0x081f6814 in Fbyte_code (bytestr=137012587, vector=137012612,
maxdepth=24) at bytecode.c:864
#12 0x081c2b84 in funcall_lambda (fun=137012524, nargs=2,
arg_vector=0xbfffe9e4) at eval.c:2962
#13 0x081c25ab in Ffuncall (nargs=3, args=0xbfffe9e0) at eval.c:2823
#14 0x081be2e3 in Fcall_interactively (function=138212161,
record_flag=137916553, keys=137975548) at callint.c:877
#15 0x08155340 in Fcommand_execute (cmd=138212161, record_flag=137916553,
keys=137916553, special=137916553) at keyboard.c:9712
#16 0x081486e2 in command_loop_1 () at keyboard.c:1785
#17 0x081c01ca in internal_condition_case (bfun=0x81472f1 <command_loop_1>,
handlers=137979985, hfun=0x8146e2e <cmd_error>) at eval.c:1385
#18 0x08147173 in command_loop_2 () at keyboard.c:1312
#19 0x081bfca9 in internal_catch (tag=137973201,
func=0x8147150 <command_loop_2>, arg=137916553) at eval.c:1144
#20 0x08147129 in command_loop () at keyboard.c:1291
#21 0x08146bb0 in recursive_edit_1 () at keyboard.c:984
#22 0x08146cf5 in Frecursive_edit () at keyboard.c:1045
#23 0x0814565b in main (argc=2, argv=0xbffff3d4) at emacs.c:1763
(gdb) xbacktrace
"yes-or-no-p"
"undo-outer-limit-truncate"
"byte-code"
"kill-region"
"call-interactively"
But when I hit C-g, Emacs does redisplay, and that in turn invokes a GC,
which asks the question again:
#0 Fyes_or_no_p (prompt=141235011) at fns.c:3279
#1 0x081c238e in Ffuncall (nargs=2, args=0xbfffdd30) at eval.c:2775
#2 0x081f6065 in Fbyte_code (bytestr=137004643, vector=137004684,
maxdepth=40) at bytecode.c:686
#3 0x081c2b84 in funcall_lambda (fun=137004612, nargs=1,
arg_vector=0xbfffdf54) at eval.c:2962
#4 0x081c25ab in Ffuncall (nargs=2, args=0xbfffdf50) at eval.c:2823
#5 0x081c1fc5 in call1 (fn=138840169, arg1=61097120) at eval.c:2569
#6 0x081a3a86 in truncate_undo_list (b=0x83931e0) at undo.c:379
#7 0x081a829e in Fgarbage_collect () at alloc.c:4687
#8 0x081c2119 in Ffuncall (nargs=2, args=0xbfffe0e0) at eval.c:2715
#9 0x081c1fc5 in call1 (fn=138013281, arg1=137972113) at eval.c:2569
#10 0x08149427 in safe_run_hooks_1 (hook=-1073749696) at keyboard.c:2037
#11 0x081c01ca in internal_condition_case (bfun=0x814940b
<safe_run_hooks_1>,
handlers=137916601, hfun=0x8149429 <safe_run_hooks_error>) at
eval.c:1385
#12 0x081494c1 in safe_run_hooks (hook=137972113) at keyboard.c:2065
#13 0x080a57df in update_menu_bar (f=0x85a4e00, save_match_data=0)
at xdisp.c:8305
#14 0x080a557f in prepare_menu_bars () at xdisp.c:8204
#15 0x080a826f in redisplay_internal (preserve_echo_area=0) at xdisp.c:9881
#16 0x080a73f4 in redisplay () at xdisp.c:9482
#17 0x08149cb9 in read_char (commandflag=1, nmaps=2, maps=0xbfffea90,
prev_event=137916553, used_mouse_menu=0xbfffeb8c) at keyboard.c:2537
#18 0x081533f3 in read_key_sequence (keybuf=0xbfffecf0, bufsize=30,
prompt=137916553, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8818
#19 0x08147690 in command_loop_1 () at keyboard.c:1531
#20 0x081c01ca in internal_condition_case (bfun=0x81472f1 <command_loop_1>,
handlers=137979985, hfun=0x8146e2e <cmd_error>) at eval.c:1385
#21 0x08147173 in command_loop_2 () at keyboard.c:1312
#22 0x081bfca9 in internal_catch (tag=137973201,
func=0x8147150 <command_loop_2>, arg=137916553) at eval.c:1144
#23 0x08147129 in command_loop () at keyboard.c:1291
#24 0x08146bb0 in recursive_edit_1 () at keyboard.c:984
#25 0x08146cf5 in Frecursive_edit () at keyboard.c:1045
#26 0x0814565b in main (argc=2, argv=0xbffff3d4) at emacs.c:1763
(gdb) xbacktrace
"yes-or-no-p"
"undo-outer-limit-truncate"
(gdb) l alloc.c:4687
4682 /* If a buffer's undo list is Qt, that means that undo is
4683 turned off in that buffer. Calling truncate_undo_list on
4684 Qt tends to return NULL, which effectively turns undo
back on.
4685 So don't call truncate_undo_list if undo_list is Qt. */
4686 if (! EQ (nextb->undo_list, Qt))
4687 truncate_undo_list (nextb);
4688
4689 /* Shrink buffer gaps, but skip indirect and dead buffers. */
4690 if (nextb->base_buffer == 0 && !NILP (nextb->name))
4691 {
(gdb)
And from that point on every C-g leads to a redisplay and a GC, and the
same place in alloc.c again, until I answer Yes or No on the question.
As for the dialog popping up, I can only assume that read_key_sequence
gets interrupted by the C-g after it has set last_nonmenu_event to Qnil,
but before it has set it to the event. This is however just
speculation, I haven't been able to actually catch that in the
debugger. Running inside the debugger has the strange side effect of
never popping up a dialog, so there might be some timing involved.
Jan D.
next prev parent reply other threads:[~2004-12-28 13:16 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-21 14:14 undo in loaddefs.el buffer Luc Teirlinck
2004-12-21 15:41 ` Luc Teirlinck
2004-12-22 4:31 ` Katsumi Yamaoka
2004-12-22 4:58 ` Katsumi Yamaoka
2004-12-23 0:01 ` Richard Stallman
2004-12-23 0:26 ` David Kastrup
2004-12-25 15:13 ` Richard Stallman
2004-12-24 1:45 ` Juri Linkov
2004-12-24 21:39 ` Luc Teirlinck
2004-12-26 9:14 ` Richard Stallman
2004-12-27 5:29 ` Luc Teirlinck
2004-12-27 22:35 ` Richard Stallman
2004-12-24 23:59 ` Luc Teirlinck
2004-12-25 15:12 ` Richard Stallman
2004-12-26 2:06 ` Luc Teirlinck
2004-12-26 2:32 ` Juri Linkov
2004-12-26 3:59 ` Luc Teirlinck
2004-12-27 2:40 ` Luc Teirlinck
2004-12-27 20:16 ` Juri Linkov
2004-12-28 4:57 ` Richard Stallman
2004-12-27 4:09 ` Richard Stallman
2004-12-26 16:15 ` Jan D.
2004-12-27 2:31 ` Luc Teirlinck
2004-12-27 10:21 ` Jan D.
2004-12-27 11:05 ` Jan D.
2004-12-27 22:35 ` Richard Stallman
2004-12-28 13:16 ` Jan D. [this message]
2004-12-28 20:57 ` Richard Stallman
2004-12-29 12:59 ` Jan D.
2004-12-28 5:03 ` Luc Teirlinck
2004-12-28 17:25 ` Richard Stallman
2004-12-29 2:07 ` Luc Teirlinck
2004-12-29 20:46 ` Richard Stallman
2004-12-30 1:14 ` Luc Teirlinck
2004-12-30 16:43 ` Richard Stallman
2004-12-31 1:54 ` Luc Teirlinck
2004-12-31 9:22 ` David Kastrup
2004-12-31 15:04 ` Luc Teirlinck
2005-01-01 5:25 ` Richard Stallman
2005-01-02 16:02 ` Luc Teirlinck
2005-01-03 0:58 ` Richard Stallman
2005-01-04 3:07 ` Luc Teirlinck
2005-01-04 17:00 ` Richard Stallman
2004-12-31 2:14 ` Luc Teirlinck
2004-12-30 5:06 ` Luc Teirlinck
2004-12-30 20:58 ` Richard Stallman
2004-12-27 18:05 ` Richard Stallman
2004-12-27 19:33 ` Jan D.
2004-12-28 4:57 ` Richard Stallman
2004-12-28 8:11 ` Jan D.
2004-12-28 21:05 ` Jason Rumney
2004-12-29 23:22 ` Jan D.
2004-12-27 4:09 ` Richard Stallman
2004-12-27 4:42 ` Luc Teirlinck
2004-12-26 2:43 ` Juri Linkov
2004-12-27 4:09 ` Richard Stallman
2005-01-04 9:05 ` Juri Linkov
2004-12-21 21:57 ` Kevin Rodgers
2004-12-22 0:17 ` Luc Teirlinck
2004-12-22 0:17 ` Richard Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41D15CBE.8060105@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
--cc=juri@jurta.org \
--cc=teirllm@dms.auburn.edu \
--cc=yamaoka@jpl.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.