[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: two related edebug problems
From: |
Chong Yidong |
Subject: |
Re: two related edebug problems |
Date: |
Wed, 09 Aug 2006 10:42:41 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
"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.
- two related edebug problems, Ken Manheimer, 2006/08/07
- Re: two related edebug problems, Richard Stallman, 2006/08/08
- Re: two related edebug problems, Ken Manheimer, 2006/08/08
- Re: two related edebug problems, Chong Yidong, 2006/08/10
- Re: two related edebug problems, Stefan Monnier, 2006/08/11
- Re: two related edebug problems, Kim F. Storm, 2006/08/11
- Re: two related edebug problems, Richard Stallman, 2006/08/12
- Re: two related edebug problems, Chong Yidong, 2006/08/12
- Re: two related edebug problems, Richard Stallman, 2006/08/12