From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: undo in loaddefs.el buffer Date: Tue, 28 Dec 2004 14:16:46 +0100 Message-ID: <41D15CBE.8060105@swipnet.se> References: <200412211414.iBLEEZ903426@raven.dms.auburn.edu> <200412211541.iBLFfBc03861@raven.dms.auburn.edu> <87llbonyup.fsf@jurta.org> <200412260206.iBQ26wG17970@raven.dms.auburn.edu> <41CEE3B8.9090600@swipnet.se> <200412270231.iBR2VDE19709@raven.dms.auburn.edu> <41CFE247.8090409@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1104239888 18452 80.91.229.6 (28 Dec 2004 13:18:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 28 Dec 2004 13:18:08 +0000 (UTC) Cc: juri@jurta.org, yamaoka@jpl.org, teirllm@dms.auburn.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 28 14:17:59 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CjHEc-00046v-00 for ; Tue, 28 Dec 2004 14:17:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CjHPT-0002Dm-GO for ged-emacs-devel@m.gmane.org; Tue, 28 Dec 2004 08:29:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CjHPD-00028p-Au for emacs-devel@gnu.org; Tue, 28 Dec 2004 08:28:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CjHPB-000274-CT for emacs-devel@gnu.org; Tue, 28 Dec 2004 08:28:54 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CjHPA-00026k-QI for emacs-devel@gnu.org; Tue, 28 Dec 2004 08:28:52 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CjHDd-000186-Lo; Tue, 28 Dec 2004 08:16:58 -0500 Original-Received: from coolsville.localdomain ([83.226.180.210] [83.226.180.210]) by mxfep01.bredband.com with ESMTP id <20041228131656.TOBI18879.mxfep01.bredband.com@coolsville.localdomain>; Tue, 28 Dec 2004 14:16:56 +0100 User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en Original-To: rms@gnu.org In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31527 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31527 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 , handlers=137979985, hfun=0x8146e2e ) at eval.c:1385 #18 0x08147173 in command_loop_2 () at keyboard.c:1312 #19 0x081bfca9 in internal_catch (tag=137973201, func=0x8147150 , 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 , handlers=137916601, hfun=0x8149429 ) 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 , handlers=137979985, hfun=0x8146e2e ) at eval.c:1385 #21 0x08147173 in command_loop_2 () at keyboard.c:1312 #22 0x081bfca9 in internal_catch (tag=137973201, func=0x8147150 , 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.