"Ken Manheimer" <address@hidden> 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.