From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thorsten Jolitz Newsgroups: gmane.emacs.help Subject: Re: Different behaviour while debugging? Date: Wed, 20 Feb 2013 16:45:35 +0100 Message-ID: <87ip5nkmzk.fsf@gmail.com> References: <87mwuzkp8i.fsf@gmail.com> <4DC3DFD1AA9D4DF69F6EB64B989F9A11@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361375182 730 80.91.229.3 (20 Feb 2013 15:46:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2013 15:46:22 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Feb 20 16:46:44 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U8BsU-0004Dz-AH for geh-help-gnu-emacs@m.gmane.org; Wed, 20 Feb 2013 16:46:38 +0100 Original-Received: from localhost ([::1]:34548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8BsA-0002jW-4N for geh-help-gnu-emacs@m.gmane.org; Wed, 20 Feb 2013 10:46:18 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8Brt-0002hx-8H for help-gnu-emacs@gnu.org; Wed, 20 Feb 2013 10:46:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U8Brm-0006F8-JN for help-gnu-emacs@gnu.org; Wed, 20 Feb 2013 10:46:01 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:47732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U8Brm-0006F2-AS for help-gnu-emacs@gnu.org; Wed, 20 Feb 2013 10:45:54 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U8Bs4-0003rv-As for help-gnu-emacs@gnu.org; Wed, 20 Feb 2013 16:46:12 +0100 Original-Received: from g231224144.adsl.alicedsl.de ([92.231.224.144]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2013 16:46:12 +0100 Original-Received: from tjolitz by g231224144.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Feb 2013 16:46:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 121 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: g231224144.adsl.alicedsl.de User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:SWvQ+RiFjKNBgelJpk2lHAS/qA8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:89185 Archived-At: "Drew Adams" writes: >> I have the very strange case that a program - in some special >> situation >> - does not work as expected, but when I instrument the relevant >> function(s) for edebug and single-step through them, everythings works >> as expected and the output is fine. >> >> There are no errors involved, so 'toggle-debug-on-error does not help. >> Its just that the program should put a buffer temporarily into a given >> major-mode and uncomment some comment-lines with 'uncomment-region' >> before turning-on Org-mode. > > Yes, it can happen that using the debugger gives you different behavior, > especially when there are changes of selected window or current buffer or frame > focus, or there is interaction with a timer or some events. It's a case of the > observer affecting the observation, in some sense. > > The debugger is pretty useful most of the time, but there are cases where you > need to find another solution. Typically you can insert calls to `message' in > the code to be debugged, perhaps with accompanying `sleep-for' or `sit-for' > calls. I inserted 'message calls in every condition-case of 'cond, and the *Messages* buffer showed that the correct condition-cases are simply not entered when run in normal mode, but are entered when in debugging mode. > Before you do that, however, try the normal Emacs debugger, `debug', instead of > `edebug'. You can use `M-x debug-on-entry' to do that. Or you can insert calls > `(debug)' in the code itself. See the manual or `C-h f debug' for more info > about using `debug'. I tried `M-x debug-on-entry', and just like with edebug, everything works fine as expected. Here the relevant code part with the message calls: ,-------------------------------------------------------------------------------- | [...] | (while (not (eobp)) | (message "Entering while-loop ...") | (cond | ;; empty line (do nothing) | ((looking-at "^[[:space:]]*$")) | ;; comment line after comment line or at | ;; beginning of buffer | ((and | (message "Before sleep [comline after comline or bobp] ...") | (progn (sleep-for 1) | (message "After sleep [comline after comline or bobp] ...")) | (message "Before checking condition [comline after comline or bobp] ...") | (save-excursion | (eq (comment-on-line-p) (point-at-bol))) | (or (bobp) last-line-comment-p)) | (message "After checking condition [comline after comline or bobp] ...") | (message "Entering comline after comline or bobp ...") | (uncomment-region (point-at-bol) (point-at-eol)) | (setq last-line-comment-p t)) | [...] `-------------------------------------------------------------------------------- Here the different - but only partly correct - output when using sleep for 1 second: ,-------------------------------------------------------------- | Entering outorg-convert-to-org.... | html-mode | Entering while-loop ... | Before sleep [comline after comline or bobp] ... | After sleep [comline after comline or bobp] ... | Before checking condition [comline after comline or bobp] ... | Entering codeline after codeline .... | Entering while-loop ... [2 times] | Before sleep [comline after comline or bobp] ... | After sleep [comline after comline or bobp] ... | Before checking condition [comline after comline or bobp] ... | Entering comline after codeline .... | Entering while-loop ... [2 times] | Before sleep [comline after comline or bobp] ... | After sleep [comline after comline or bobp] ... | Before checking condition [comline after comline or bobp] ... | Entering codeline after comline .... `-------------------------------------------------------------- here again the entirely incorrect output after outcommenting ,------------------------------------------------------------- | (progn (sleep-for 1) | (message "After sleep [comline after comline or bobp] ...")) `------------------------------------------------------------- in the code example above: ,-------------------------------------------------------------- | Entering outorg-convert-to-org.... | html-mode | Entering while-loop ... | Before sleep [comline after comline or bobp] ... | Before checking condition [comline after comline or bobp] ... | Entering codeline after codeline .... | Entering while-loop ... [2 times] | Before sleep [comline after comline or bobp] ... | Before checking condition [comline after comline or bobp] ... | Entering codeline after codeline .... | Entering while-loop ... [2 times] | Before sleep [comline after comline or bobp] ... | Before checking condition [comline after comline or bobp] ... | Entering codeline after codeline .... `-------------------------------------------------------------- from this evidence, I would conclude that slowing down the program by 1 second makes it partly behaving correct, but *really* slowing it down by single-stepping in the debugger (no matter if debug or edebug) makes it behave correctly. Not really what I would expect... -- cheers, Thorsten