two related edebug problems

two related edebug problems

[Ken Manheimer]

i've been hitting two elusive edebug problems, one new and one that's
been happening for a while.  i find edebug hard to debug, so i'm
hoping i might be able to just precipitate investigation by someone
more experienced with it.

i hadn't noticed this first problem until recently, though it may have
been happening before but less frequently.  sometimes when i'm
stepping through code, any of the progress commands always single step
- when i try to contiue (edebug-continue-mode), step over
(edebug-forward-sexp), out, and even go or edebug-goto-here, i always
get a single step from the current step.  generally a fresh edebug
session doesn't have the problem.  i haven't identified when the
problem starts, or what particular action is associated with its
onset.

the second problem is something i've noticed on several occasions over
time.  edebug-step-in causes a traceback, with an odd complaint:
Lisp error: (void-variable {).  the full stack trace is included
below.

i think the second problem happens when the first one is happening,
maybe only when it's happening.

both of these problems usually make the current edebug excursion
futile.  sometimes i have to work hard to be able to quit with leaving
things fouled.

is this ringing any bells?

here's the full traceback.  this time it happens to be during a
post-command-hook investigation, but i can't say that it is restricted
to such a special context.  it certainly doesn't always happen in such
a context.

Debugger entered--Lisp error: (void-variable {)
  apply(debug error (void-variable {))
  edebug(error (void-variable {))
  signal(void-variable ({))
  edebug-signal(void-variable ({))
  (edebug-after 0 0 {)
  (lambda nil (edebug-after 0 0 {))()
  edebug-enter(edebug-anon2 nil (lambda nil (edebug-after 0 0 {)))
  edebug-enter(edebug-anon2 nil (lambda nil (edebug-after 0 0 {)))
  eval((edebug-enter (quote edebug-anon2) nil (function (lambda nil ...))))
  eval-expression((edebug-enter (quote edebug-anon2) nil (function
(lambda nil ...))))
  edebug-eval-top-level-form()
  edebug-instrument-function(widget-apply)
  edebug-instrument-callee()
  edebug-step-in()
  call-interactively(edebug-step-in)
  recursive-edit()
  edebug-recursive-edit()
  edebug-display()
  edebug-debugger(169 before nil)
  edebug-before(169)
  (edebug-after (edebug-before 169) 171 (widget-apply (edebug-after 0
170 doing-item) :decorate-guides))
  (progn (edebug-after (edebug-before 134) 137 (widget-apply ...
:parse-item t ...)) (edebug-after (edebug-before 138) 156 (if ...
...)) (edebug-after (edebug-before 157) 168 (setq doing-guides-changed
...)) (edebug-after (edebug-before 169) 171 (widget-apply ...
:decorate-guides)) (edebug-after (edebug-before 172) 174 (widget-apply
... :decorate-icon)) (edebug-after (edebug-before 175) 177
(widget-apply ... :decorate-cue)) (edebug-after (edebug-before 178)
180 (widget-apply ... :decorate-body)) (edebug-after (edebug-before
181) 184 (widget-put ... :last-decorated-tick ...)))
  (if (edebug-after (edebug-before 123) 133 (or ... ...)) (progn
(edebug-after ... 137 ...) (edebug-after ... 156 ...) (edebug-after
... 168 ...) (edebug-after ... 171 ...) (edebug-after ... 174 ...)
(edebug-after ... 177 ...) (edebug-after ... 180 ...) (edebug-after
... 184 ...)))
  (when (edebug-after (edebug-before 123) 133 (or ... ...))
(edebug-after (edebug-before 134) 137 (widget-apply ... :parse-item t
...)) (edebug-after (edebug-before 138) 156 (if ... ...))
(edebug-after (edebug-before 157) 168 (setq doing-guides-changed ...))
(edebug-after (edebug-before 169) 171 (widget-apply ...
:decorate-guides)) (edebug-after (edebug-before 172) 174 (widget-apply
... :decorate-icon)) (edebug-after (edebug-before 175) 177
(widget-apply ... :decorate-cue)) (edebug-after (edebug-before 178)
180 (widget-apply ... :decorate-body)) (edebug-after (edebug-before
181) 184 (widget-put ... :last-decorated-tick ...)))
  (edebug-after (edebug-before 122) 185 (when (edebug-after ... 133
...) (edebug-after ... 137 ...) (edebug-after ... 156 ...)
(edebug-after ... 168 ...) (edebug-after ... 171 ...) (edebug-after
... 174 ...) (edebug-after ... 177 ...) (edebug-after ... 180 ...)
(edebug-after ... 184 ...)))
  (while --cl-dolist-temp-- (setq doing-at (car --cl-dolist-temp--))
(edebug-after (edebug-before 103) 105 (goto-char ...)) (edebug-after
(edebug-before 106) 121 (setq doing-item ...)) (edebug-after
(edebug-before 122) 185 (when ... ... ... ... ... ... ... ... ...))
(edebug-after (edebug-before 186) 188 (setq successor-sibling ...))
(setq --cl-dolist-temp-- (cdr --cl-dolist-temp--)))
  (let ((--cl-dolist-temp-- ...) doing-at) (while --cl-dolist-temp--
(setq doing-at ...) (edebug-after ... 105 ...) (edebug-after ... 121
...) (edebug-after ... 185 ...) (edebug-after ... 188 ...) (setq
--cl-dolist-temp-- ...)) nil)
  (catch (quote --cl-block-nil--) (let (... doing-at) (while
--cl-dolist-temp-- ... ... ... ... ... ...) nil))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
  (block nil (let (... doing-at) (while --cl-dolist-temp-- ... ... ...
... ... ...) nil))
  (dolist (doing-at (edebug-after 0 102 reverse-siblings-chart))
(edebug-after (edebug-before 103) 105 (goto-char ...)) (edebug-after
(edebug-before 106) 121 (setq doing-item ...)) (edebug-after
(edebug-before 122) 185 (when ... ... ... ... ... ... ... ... ...))
(edebug-after (edebug-before 186) 188 (setq successor-sibling ...)))
  (edebug-after (edebug-before 101) 189 (dolist (doing-at ...)
(edebug-after ... 105 ...) (edebug-after ... 121 ...) (edebug-after
... 185 ...) (edebug-after ... 188 ...)))
  (let* ((allout-inhibit-body-modification-hook t) (item-type ...)
(was-modified ...) (was-point ...) prefix-start (is-container ...)
(steady-point ...) (steady-point ...) (parent ...) (parent-flags ...)
successor-sibling body doing-item doing-guides-changed sub-item-widget
depth reverse-siblings-chart) (edebug-after (edebug-before 58) 100 (if
... ... ... ... ... ... ...)) (edebug-after (edebug-before 101) 189
(dolist ... ... ... ... ...)) (edebug-after (edebug-before 190) 192
(set-buffer-modified-p ...)) (edebug-after (edebug-before 193) 195
(goto-char ...)) (edebug-after (edebug-before 196) 198 (set-marker ...
nil)) (edebug-after 0 199 item-widget))
  (edebug-after (edebug-before 12) 200 (let* (... ... ... ...
prefix-start ... ... ... ... ... successor-sibling body doing-item
doing-guides-changed sub-item-widget depth reverse-siblings-chart)
(edebug-after ... 100 ...) (edebug-after ... 189 ...) (edebug-after
... 192 ...) (edebug-after ... 195 ...) (edebug-after ... 198 ...)
(edebug-after 0 199 item-widget)))
  (progn (edebug-after (edebug-before 12) 200 (let* ... ... ... ...
... ... ...)))
  (if (edebug-after (edebug-before 1) 11 (or ... ...)) (progn
(edebug-after ... 200 ...)))
  (when (edebug-after (edebug-before 1) 11 (or ... ...)) (edebug-after
(edebug-before 12) 200 (let* ... ... ... ... ... ... ...)))
  (edebug-after (edebug-before 0) 201 (when (edebug-after ... 11 ...)
(edebug-after ... 200 ...)))
  (lambda nil (edebug-after (edebug-before 0) 201 (when ... ...)))()
  edebug-enter(allout-decorate-item-and-context ((allout-item-widget
:depth 5 :from 190971 :bullet-at 190975 :prefix-end 190976 :cue-end
190977 :body-end 194603 :settings-start nil :settings-assimilated t
:to 194603 :has-contents nil :expanded nil :guide-column-flags (t nil
t) :was-guide-column-flags (t nil t) :guides-overlay #<overlay from
190971 to 190975 in did> :was-expanded nil :was-has-contents nil
:was-does-encrypt nil :was-is-encrypted nil :icon-overlay #<overlay
from 190975 to 190976 in did> :cue-overlay #<overlay from 190976 to
190977 in did> :body-overlay #<overlay from 190977 to 194603 in did>
:last-decorated-tick 13410) redecorate nil (allout-item-widget :depth
4 :from 190929 :bullet-at 190932 :prefix-end 190933 :cue-end 190934
:body-end 190970 :settings-start nil :settings-assimilated t :to
190970 :has-contents t :expanded t :guide-column-flags (nil t)
:was-guide-column-flags (nil t) :guides-overlay #<overlay from 190929
to 190932 in did> :was-expanded t :was-has-contents t
:was-does-encrypt nil :was-is-encrypted nil :icon-overlay #<overlay
from 190932 to 190933 in did> :cue-overlay #<overlay from 190933 to
190934 in did> :body-overlay #<overlay from 190934 to 190970 in did>
:last-decorated-tick 13415)) (lambda nil (edebug-after (edebug-before
0) 201 (when ... ...))))
  allout-decorate-item-and-context((allout-item-widget :depth 5 :from
190971 :bullet-at 190975 :prefix-end 190976 :cue-end 190977 :body-end
194603 :settings-start nil :settings-assimilated t :to 194603
:has-contents nil :expanded nil :guide-column-flags (t nil t)
:was-guide-column-flags (t nil t) :guides-overlay #<overlay from
190971 to 190975 in did> :was-expanded nil :was-has-contents nil
:was-does-encrypt nil :was-is-encrypted nil :icon-overlay #<overlay
from 190975 to 190976 in did> :cue-overlay #<overlay from 190976 to
190977 in did> :body-overlay #<overlay from 190977 to 194603 in did>
:last-decorated-tick 13410) redecorate nil (allout-item-widget :depth
4 :from 190929 :bullet-at 190932 :prefix-end 190933 :cue-end 190934
:body-end 190970 :settings-start nil :settings-assimilated t :to
190970 :has-contents t :expanded t :guide-column-flags (nil t)
:was-guide-column-flags (nil t) :guides-overlay #<overlay from 190929
to 190932 in did> :was-expanded t :was-has-contents t
:was-does-encrypt nil :was-is-encrypted nil :icon-overlay #<overlay
from 190932 to 190933 in did> :cue-overlay #<overlay from 190933 to
190934 in did> :body-overlay #<overlay from 190934 to 190970 in did>
:last-decorated-tick 13415))
  (edebug-after (edebug-before 52) 55
(allout-decorate-item-and-context (edebug-after 0 53 item-widget)
(quote redecorate) nil (edebug-after 0 54 parent-widget)))
  (if (edebug-after (edebug-before 48) 51 (setq item-widget ...))
(edebug-after (edebug-before 52) 55 (allout-decorate-item-and-context
... ... nil ...)) (edebug-after (edebug-before 56) 57
(allout-get-or-create-item-widget)))
  (edebug-after (edebug-before 47) 58 (if (edebug-after ... 51 ...)
(edebug-after ... 55 ...) (edebug-after ... 57 ...)))
  (progn (edebug-after (edebug-before 44) 46 (goto-char ...))
(edebug-after (edebug-before 47) 58 (if ... ... ...)))
  (if (edebug-after (edebug-before 41) 43 (not ...)) (progn
(edebug-after ... 46 ...) (edebug-after ... 58 ...)))
  (when (edebug-after (edebug-before 41) 43 (not ...)) (edebug-after
(edebug-before 44) 46 (goto-char ...)) (edebug-after (edebug-before
47) 58 (if ... ... ...)))
  (edebug-after (edebug-before 40) 59 (when (edebug-after ... 43 ...)
(edebug-after ... 46 ...) (edebug-after ... 58 ...)))
  (cond ((edebug-after ... 39 ...) (edebug-after ... 59 ...)
(edebug-after ... 63 ...)) ((edebug-after ... 66 ...) (edebug-after
... 77 ...)))
  (edebug-after (edebug-before 36) 78 (cond (... ... ...) (... ...)))
  (while --cl-dolist-temp-- (setq sibling-point (car
--cl-dolist-temp--)) (edebug-after (edebug-before 36) 78 (cond ...
...)) (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--)))
  (let ((--cl-dolist-temp-- ...) sibling-point) (while
--cl-dolist-temp-- (setq sibling-point ...) (edebug-after ... 78 ...)
(setq --cl-dolist-temp-- ...)) nil)
  (catch (quote --cl-block-nil--) (let (... sibling-point) (while
--cl-dolist-temp-- ... ... ...) nil))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
  (block nil (let (... sibling-point) (while --cl-dolist-temp-- ...
... ...) nil))
  (dolist (sibling-point (edebug-after 0 35 pending-chart))
(edebug-after (edebug-before 36) 78 (cond ... ...)))
  (edebug-after (edebug-before 34) 79 (dolist (sibling-point ...)
(edebug-after ... 78 ...)))
  (let ((parent-widget ...) (pending-chart ...) item-widget
previous-sibling-point previous-sibling recent-sibling-point)
(edebug-after (edebug-before 29) 33 (setq pending-chart ...))
(edebug-after (edebug-before 34) 79 (dolist ... ...)) (edebug-after
(edebug-before 80) 92 (if ... ...)))
  (edebug-after (edebug-before 0) 93 (let (... ... item-widget
previous-sibling-point previous-sibling recent-sibling-point)
(edebug-after ... 33 ...) (edebug-after ... 79 ...) (edebug-after ...
92 ...)))
  (lambda nil (edebug-after (edebug-before 0) 93 (let ... ... ... ...)))()
  edebug-enter(allout-redecorate-visible-subtree (nil nil) (lambda nil
(edebug-after (edebug-before 0) 93 (let ... ... ... ...))))
  allout-redecorate-visible-subtree()
  (edebug-after (edebug-before 45) 46 (allout-redecorate-visible-subtree))
  (if (edebug-after (edebug-before 43) 44 (allout-ascend))
(edebug-after (edebug-before 45) 46
(allout-redecorate-visible-subtree)))
  (edebug-after (edebug-before 42) 47 (if (edebug-after ... 44 ...)
(edebug-after ... 46 ...)))
  (progn (edebug-after (edebug-before 39) 41 (goto-char ...))
(edebug-after (edebug-before 42) 47 (if ... ...)) (edebug-after
(edebug-before 48) 57 (if ... ...)) (edebug-after (edebug-before 58)
76 (while ... ... ... ...)) (edebug-after (edebug-before 77) 97 (if
... ...)))
  (if (edebug-after (edebug-before 36) 38 (not ...)) (progn
(edebug-after ... 41 ...) (edebug-after ... 47 ...) (edebug-after ...
57 ...) (edebug-after ... 76 ...) (edebug-after ... 97 ...)))
  (when (edebug-after (edebug-before 36) 38 (not ...)) (edebug-after
(edebug-before 39) 41 (goto-char ...)) (edebug-after (edebug-before
42) 47 (if ... ...)) (edebug-after (edebug-before 48) 57 (if ... ...))
(edebug-after (edebug-before 58) 76 (while ... ... ... ...))
(edebug-after (edebug-before 77) 97 (if ... ...)))
  (edebug-after (edebug-before 35) 98 (when (edebug-after ... 38 ...)
(edebug-after ... 41 ...) (edebug-after ... 47 ...) (edebug-after ...
57 ...) (edebug-after ... 76 ...) (edebug-after ... 97 ...)))
  (let ((from ...) bucket (to ...)) (edebug-after (edebug-before 11)
21 (if ... ...)) (edebug-after (edebug-before 22) 34 (setq handled ...
covered ... handled ...)) (edebug-after (edebug-before 35) 98 (when
... ... ... ... ... ...)))
  (edebug-after (edebug-before 4) 99 (let (... bucket ...)
(edebug-after ... 21 ...) (edebug-after ... 34 ...) (edebug-after ...
98 ...)))
  (while --cl-dolist-temp-- (setq change (car --cl-dolist-temp--))
(edebug-after (edebug-before 4) 99 (let ... ... ... ...)) (setq
--cl-dolist-temp-- (cdr --cl-dolist-temp--)))
  (let ((--cl-dolist-temp-- ...) change) (while --cl-dolist-temp--
(setq change ...) (edebug-after ... 99 ...) (setq --cl-dolist-temp--
...)) nil)
  (catch (quote --cl-block-nil--) (let (... change) (while
--cl-dolist-temp-- ... ... ...) nil))
  (cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
  (block nil (let (... change) (while --cl-dolist-temp-- ... ... ...) nil))
  (dolist (change (edebug-after 0 3 changes)) (edebug-after
(edebug-before 4) 99 (let ... ... ... ...)))
  (edebug-after (edebug-before 2) 100 (dolist (change ...)
(edebug-after ... 99 ...)))
  (let ((handled nil) covered) (edebug-after (edebug-before 2) 100
(dolist ... ...)))
  (edebug-after (edebug-before 1) 101 (let (... covered) (edebug-after
... 100 ...)))
  (save-excursion (edebug-after (edebug-before 1) 101 (let ... ...)))
  (edebug-after (edebug-before 0) 102 (save-excursion (edebug-after
... 101 ...)))
  (lambda nil (edebug-after (edebug-before 0) 102 (save-excursion ...)))()
  edebug-enter(allout-widgets-additions-processor (((:added 199101
199108))) (lambda nil (edebug-after (edebug-before 0) 102
(save-excursion ...))))
  edebug-enter(allout-widgets-additions-processor (((:added 199101
199108))) (lambda nil (edebug-after (edebug-before 0) 102
(save-excursion ...))))
  allout-widgets-additions-processor(((:added 199101 199108)))
  (if additions (allout-widgets-additions-processor additions))
  (progn (while changes-record (setq entry ...) (case ... ... ... ...
...)) (if exposures (allout-widgets-exposure-change-processor
exposures)) (if additions (allout-widgets-additions-processor
additions)) (if deletions (allout-widgets-deletions-processor
deletions)) (if shifts (allout-widgets-shifts-processor shifts)))
  (if changes-pending (progn (while changes-record ... ...) (if
exposures ...) (if additions ...) (if deletions ...) (if shifts ...)))
  (when changes-pending (while changes-record (setq entry ...) (case
... ... ... ... ...)) (if exposures
(allout-widgets-exposure-change-processor exposures)) (if additions
(allout-widgets-additions-processor additions)) (if deletions
(allout-widgets-deletions-processor deletions)) (if shifts
(allout-widgets-shifts-processor shifts)))
  (let ((changes-pending ...) entry exposures additions deletions
shifts) (when changes-pending (while changes-record ... ...) (if
exposures ...) (if additions ...) (if deletions ...) (if shifts ...)))
  allout-widgets-changes-dispatcher(((:added 199101 199108)))
  allout-widgets-post-command-business()
  run-hooks(post-command-hook)


-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

Re: two related edebug problems

[Richard Stallman]

      (edebug-after 0 0 {)
      (lambda nil (edebug-after 0 0 {))()
      edebug-enter(edebug-anon2 nil (lambda nil (edebug-after 0 0 {)))
      edebug-enter(edebug-anon2 nil (lambda nil (edebug-after 0 0 {)))
      eval((edebug-enter (quote edebug-anon2) nil (function (lambda nil ...))))
      eval-expression((edebug-enter (quote edebug-anon2) nil (function
    (lambda nil ...))))

I suggest you examine that function without abbreviation
so we can see if it uses the variable {.

What function is it?  Does it have a name?
What does its source code look like?

Re: two related edebug problems

[Ken Manheimer]

i can reproduce this traceback easily, but for a somewhat extreme
action.  it happens any time i try to step into builtin, ie C coded,
functions.  that's whether or not emacs is started -Q.  (i thought i
saw emacs loading up C mode, as if it was going to step through the C
level code - is it now able to do that?)

i can't say whether or not i was seeing it when trying to step into
lisp-level functions, though i thought i was when the first problem i
described was happening.

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 is with a cvs HEAD emacs cvs upped and compiled in the last 1/2
hour.  (i did make clean / configure / make / make install.  this
original checkout was compiled once before, because i wanted to see
whether these problems might be in some state not cleaned by
distclean.)

On 8/8/06, Richard Stallman <rms@gnu.org> wrote:
>       (edebug-after 0 0 {)
>       (lambda nil (edebug-after 0 0 {))()
>       edebug-enter(edebug-anon2 nil (lambda nil (edebug-after 0 0 {)))
>       edebug-enter(edebug-anon2 nil (lambda nil (edebug-after 0 0 {)))
>       eval((edebug-enter (quote edebug-anon2) nil (function (lambda nil ...))))
>       eval-expression((edebug-enter (quote edebug-anon2) nil (function
>     (lambda nil ...))))
>
> I suggest you examine that function without abbreviation
> so we can see if it uses the variable {.
>
> What function is it?  Does it have a name?
> What does its source code look like?
>


-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net

Re: two related edebug problems

[Chong Yidong]

"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.

Re: two related edebug problems

[Ken Manheimer]

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

Re: two related edebug problems

[Richard Stallman]

    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.

How about making input-pending-p reliable
by making it use the new read-event timeout argument.
If it gets an event, it can unread the event.

Re: two related edebug problems

[Chong Yidong]

I found out the cause of the bug.  edebug-display calls sit-for to
pause before displaying eval results, then calls
edebug-recursive-edit.  However, edebug-recursive-edit rebinds
unread-command-events, causing sit-for interruptions (which are put
into unread-command-events) to go unnoticed.  This creates problems
when you type in edebug commands in quick succession.  I fixed this by
moving the rebinding of unread-command-events to edebug-display.

Edebug should probably work now.

Re: two related edebug problems

[Stefan Monnier]

> I found out the cause of the bug.  edebug-display calls sit-for to
> pause before displaying eval results, then calls
> edebug-recursive-edit.  However, edebug-recursive-edit rebinds
> unread-command-events, causing sit-for interruptions (which are put
> into unread-command-events) to go unnoticed.  This creates problems
> when you type in edebug commands in quick succession.  I fixed this by
> moving the rebinding of unread-command-events to edebug-display.

This is a workaround rather than a fix.  A real fix would be to change
sit-for so it doesn't use unread-command-events but an internal variable
instead with which other code can't mess.


        Stefan

Re: two related edebug problems

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This is a workaround rather than a fix.  A real fix would be to change
> sit-for so it doesn't use unread-command-events but an internal variable
> instead with which other code can't mess.

We currently have the following "unread event" variables (in order of usage):

unread-post-input-method-events
unread-command-char   (obsolete)
unread-command-events
unread-input-method-events
<keyboard macros>
unread_switch_frame (C internal)

At which step should unread-sit-for-event be placed?

I.e. if some timer function actually places something on
unread-command-events, should that be interpreted before or after
unread-sit-for-event ??


BTW, unread-post-input-method-events and unread-input-method-events
have the _same_ doc string:

  List of events to be processed as input by input methods.
  These events are processed after `unread-command-events', but
  before actual keyboard input.  */);

According to the sequence in the code, "after" should be "before"
for unread-post-input-method-events.

But the name of these vars puzzles me...  since the -post- thing
is actually run _before_ the other vars...??

Maybe the doc strings need some clarification...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: two related edebug problems

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I found out the cause of the bug.  edebug-display calls sit-for to
>> pause before displaying eval results, then calls
>> edebug-recursive-edit.  However, edebug-recursive-edit rebinds
>> unread-command-events, causing sit-for interruptions (which are put
>> into unread-command-events) to go unnoticed.  This creates problems
>> when you type in edebug commands in quick succession.  I fixed this by
>> moving the rebinding of unread-command-events to edebug-display.
>
> This is a workaround rather than a fix.  A real fix would be to change
> sit-for so it doesn't use unread-command-events but an internal variable
> instead with which other code can't mess.

Is this really necessary?  It seems to me that code that messes with
unread-command-events should simply take the behavior of sit-for into
account, and avoid breaking it.  I'm not sure this situation arises
often enough to justify introducing a separate unread-command-events
mechanism for sit-for.

Re: two related edebug problems

[Richard Stallman]

    > I found out the cause of the bug.  edebug-display calls sit-for to
    > pause before displaying eval results, then calls
    > edebug-recursive-edit.  However, edebug-recursive-edit rebinds
    > unread-command-events, causing sit-for interruptions (which are put
    > into unread-command-events) to go unnoticed.  This creates problems
    > when you type in edebug commands in quick succession.  I fixed this by
    > moving the rebinding of unread-command-events to edebug-display.

    This is a workaround rather than a fix.  A real fix would be to change
    sit-for so it doesn't use unread-command-events but an internal variable
    instead with which other code can't mess.

I disagree.  unread-command-events is defined to do what it does.  If
Lisp code sets it to nil, that gets rid of the pending events.  If
Lisp code later sets it back to something non-nil, that restores them.
If the result of doing that isn't what you want, you should not do that.

Re: two related edebug problems

[Richard Stallman]

    BTW, unread-post-input-method-events and unread-input-method-events
    have the _same_ doc string:

      List of events to be processed as input by input methods.
      These events are processed after `unread-command-events', but
      before actual keyboard input.  */);

    According to the sequence in the code, "after" should be "before"
    for unread-post-input-method-events.

Handa san, could you please look this, and DTRT, then ack this message?