Re: two related edebug problems

["Ken Manheimer" <ken.manheimer@gmail.com>]

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 <cyd@stupidchicken.com> wrote:
> "Ken Manheimer" <ken.manheimer@gmail.com> 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