From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: two related edebug problems Date: Wed, 9 Aug 2006 15:42:39 -0400 Message-ID: <2cd46e7f0608091242t3cd240br601b97e0535d6024@mail.gmail.com> References: <2cd46e7f0608071130o7d72123ct82841031bf757f5d@mail.gmail.com> <2cd46e7f0608081226o63f2a0d5q9e79575021d0a181@mail.gmail.com> <87hd0mhswu.fsf@stupidchicken.com> NNTP-Posting-Host: main.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 1155152585 31935 80.91.229.2 (9 Aug 2006 19:43:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Aug 2006 19:43:05 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 09 21:43:02 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GAtxF-0002Fp-Gl for ged-emacs-devel@m.gmane.org; Wed, 09 Aug 2006 21:43:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GAtxE-000340-Tf for ged-emacs-devel@m.gmane.org; Wed, 09 Aug 2006 15:43:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GAtwx-0002yZ-Rg for emacs-devel@gnu.org; Wed, 09 Aug 2006 15:42:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GAtwv-0002um-JY for emacs-devel@gnu.org; Wed, 09 Aug 2006 15:42:43 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GAtwv-0002ua-Ef for emacs-devel@gnu.org; Wed, 09 Aug 2006 15:42:41 -0400 Original-Received: from [64.233.182.188] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GAu1f-00048l-Kr for emacs-devel@gnu.org; Wed, 09 Aug 2006 15:47:35 -0400 Original-Received: by nf-out-0910.google.com with SMTP id h2so264479nfe for ; Wed, 09 Aug 2006 12:42:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G8v29WsvnfWQklP6/+lnWYgHwB92243rPzBB953grQZpy9Y56rJYavQqA04u36jsh8OAyTxwi5jj3FB8AAqDHGL3wYtlAmz8zTxGhPL2SfypbMN7ocUf1fvCmpgsR/MoIj7gxl7BgzSP3IdtxlUohWjFK5RSALcpbT5t0Vk4vwM= Original-Received: by 10.78.170.6 with SMTP id s6mr613418hue; Wed, 09 Aug 2006 12:42:39 -0700 (PDT) Original-Received: by 10.78.202.13 with HTTP; Wed, 9 Aug 2006 12:42:39 -0700 (PDT) Original-To: "Chong Yidong" In-Reply-To: <87hd0mhswu.fsf@stupidchicken.com> Content-Disposition: inline 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: news.gmane.org gmane.emacs.devel:58235 Archived-At: thanks for investigating! commenting out the code you identify does alleviate the problem for me. i notice that i still need to hit 'f' twice each time i want to traverse an sexp. i also now notice that there's a spurious pause of two or three seconds after each 'f' that actually does traversal, before the "Break" message is displayed. (and, of course, stepping into C level functions continue to cause an odd traceback - though i realize your investigation wasn't concerned with that problem.) altogether, navigating the current problems in edebug makes debugging difficult. i'm very glad to have a workaround for the insistent single-stepping - thanks! ken On 8/9/06, Chong Yidong wrote: > "Ken Manheimer" writes: > > > i am able to reliably reproduce the first problem (always single > > stepping). i open a new emacs session with emacs -Q, find the > > standard `newline' function (in simple.el - i just use > > `find-function'), edebug-defun it, then do a newline in the scratch > > buffer. if i just use "f" to step through, it almost immediately goes > > into the always-single-step mode - after `(barf-if-buffer-read-only)'. > > "c", "o", "f", "h", all work like hitting the space bar. > > This seems to be triggered by the following code in edebug-display: > > (if (edebug-input-pending-p) > (progn > (setq edebug-execution-mode 'step > edebug-stop t) > (edebug-stop) > ;; (discard-input) ; is this unfriendly?? > )) > > Commenting this out removes the problem, but this is probably not what > we want. My guess is that input-pending-p is returning spuriously (it > does not guarantee that there is really input pending). > > One possibility is to make use of the sit-for statements further down > in edebug-display. Since sit-for now returns iff there is real input, > we could capture the return value and use that to determine whether to > stop execution. > -- ken ken.manheimer@gmail.com http://myriadicity.net