bug#20074: edebug tracing can't be stopped with 'S'

bug#20074: edebug tracing can't be stopped with 'S'

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

I start emacs with "runemacs -Q", on windows 8.
Then i write the following function in the scratch buffer:

(defun forever ()
  (interactive)
  (while t (message "doing nothing")))

I then press C-u C-M-x to instrument the function for debugging.  Then i
do M-x forever. Then i press 't' to start tracing, and edebug starts
tracing the code correctly. However, if i press 'S' to stop, it doesn't
work. Pressing many 'S' commands repeatedly apparently only cause edebug
to evaluate the 'while' expression faster. Pressing 'q', <SPC>, 'n', do
not seem to stop edebug either, they only appear to speed up the
evaluation of the code. I have to press C-g then 'q' to return me to the
toplevel.

In GNU Emacs 24.4.1 (i686-pc-mingw32)
 of 2014-10-24 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --prefix=/c/usr'

Important settings:
  value of $LANG: ESM
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
( d e f u n SPC f o r e v e r SPC ( ) <return> ( i
n t e r a c t i v e ) <return> ( m e s s a g e SPC
" d o i n t <backspace> g SPC n o t h i n g " ) ) <up>
<return> ( w h i l t <backspace> e SPC t <down> <tab>
C-e ) C-u C-M-x M-x f o r e v e r <return> t S S S
S S S S S S S S S S S S S S S S S T t S c c g g g g
g g g g q q q q q q q q q C-g q <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
doing nothing
Result: "doing nothing"
doing nothing
Result: "doing nothing"
doing nothing
Result: "doing nothing"
doing nothing
Result: "doing nothing"
Quit
Back to top level.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils edebug easymenu cl-loaddefs cl-lib
time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 77731 5671)
 (symbols 32 18075 0)
 (miscs 32 35 96)
 (strings 16 12535 3467)
 (string-bytes 1 339295)
 (vectors 8 9742)
 (vector-slots 4 388212 4546)
 (floats 8 55 244)
 (intervals 28 240 35)
 (buffers 508 11))

[-- Attachment #2: Type: text/html, Size: 4737 bytes --]

bug#20074: edebug tracing can't be stopped with 'S'

[Eli Zaretskii]

> Date: Tue, 10 Mar 2015 14:42:07 -0600
> From: Mario Valencia <mariovalspi@gmail.com>
> 
> I start emacs with "runemacs -Q", on windows 8.
> Then i write the following function in the scratch buffer:
> 
> (defun forever ()
> (interactive)
> (while t (message "doing nothing")))
> 
> I then press C-u C-M-x to instrument the function for debugging. Then i
> do M-x forever. Then i press 't' to start tracing, and edebug starts
> tracing the code correctly. However, if i press 'S' to stop, it doesn't
> work. Pressing many 'S' commands repeatedly apparently only cause edebug
> to evaluate the 'while' expression faster. Pressing 'q', <SPC>, 'n', do
> not seem to stop edebug either, they only appear to speed up the
> evaluation of the code. I have to press C-g then 'q' to return me to the
> toplevel.

First, I see this on GNU/Linux as well, so it's not Windows-specific,
at least.

And second, did this ever work as you expect?  I tried as far back as
Emacs 23.3, and I see the same behavior.  Moreover, the ELisp manual
doesn't say anything about 'S' interrupting a trace, at least
according to my reading.

bug#20074: Fwd: bug#20074: edebug tracing can't be stopped with 'S'

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

---------- Forwarded message ----------
From: Mario Valencia <mariovalspi@gmail.com>
Date: 2015-03-11 10:26 GMT-06:00
Subject: Re: bug#20074: edebug tracing can't be stopped with 'S'
To: Eli Zaretskii <eliz@gnu.org>


Its never worked and the manual implies it should. Even if the manual
didnt, it still should work.
El mar 11, 2015 10:24 a.m., "Eli Zaretskii" <eliz@gnu.org> escribió:

> Date: Tue, 10 Mar 2015 14:42:07 -0600
> > From: Mario Valencia <mariovalspi@gmail.com>
> >
> > I start emacs with "runemacs -Q", on windows 8.
> > Then i write the following function in the scratch buffer:
> >
> > (defun forever ()
> > (interactive)
> > (while t (message "doing nothing")))
> >
> > I then press C-u C-M-x to instrument the function for debugging. Then i
> > do M-x forever. Then i press 't' to start tracing, and edebug starts
> > tracing the code correctly. However, if i press 'S' to stop, it doesn't
> > work. Pressing many 'S' commands repeatedly apparently only cause edebug
> > to evaluate the 'while' expression faster. Pressing 'q', <SPC>, 'n', do
> > not seem to stop edebug either, they only appear to speed up the
> > evaluation of the code. I have to press C-g then 'q' to return me to the
> > toplevel.
>
> First, I see this on GNU/Linux as well, so it's not Windows-specific,
> at least.
>
> And second, did this ever work as you expect?  I tried as far back as
> Emacs 23.3, and I see the same behavior.  Moreover, the ELisp manual
> doesn't say anything about 'S' interrupting a trace, at least
> according to my reading.
>

[-- Attachment #2: Type: text/html, Size: 2371 bytes --]

bug#20074: edebug tracing can't be stopped with 'S'

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

From the manual:

While executing or tracing, you can interrupt the execution by typing
any Edebug command.  Edebug stops the program at the next stop point and
then executes the command you typed.  For example, typing `t' during
execution switches to trace mode at the next stop point.  You can use
`S' to stop execution without doing anything else.


2015-03-11 10:28 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:

> ---------- Forwarded message ----------
> From: Mario Valencia <mariovalspi@gmail.com>
> Date: 2015-03-11 10:26 GMT-06:00
> Subject: Re: bug#20074: edebug tracing can't be stopped with 'S'
> To: Eli Zaretskii <eliz@gnu.org>
>
>
> Its never worked and the manual implies it should. Even if the manual
> didnt, it still should work.
> El mar 11, 2015 10:24 a.m., "Eli Zaretskii" <eliz@gnu.org> escribió:
>
> > Date: Tue, 10 Mar 2015 14:42:07 -0600
>> > From: Mario Valencia <mariovalspi@gmail.com>
>> >
>> > I start emacs with "runemacs -Q", on windows 8.
>> > Then i write the following function in the scratch buffer:
>> >
>> > (defun forever ()
>> > (interactive)
>> > (while t (message "doing nothing")))
>> >
>> > I then press C-u C-M-x to instrument the function for debugging. Then i
>> > do M-x forever. Then i press 't' to start tracing, and edebug starts
>> > tracing the code correctly. However, if i press 'S' to stop, it doesn't
>> > work. Pressing many 'S' commands repeatedly apparently only cause edebug
>> > to evaluate the 'while' expression faster. Pressing 'q', <SPC>, 'n', do
>> > not seem to stop edebug either, they only appear to speed up the
>> > evaluation of the code. I have to press C-g then 'q' to return me to the
>> > toplevel.
>>
>> First, I see this on GNU/Linux as well, so it's not Windows-specific,
>> at least.
>>
>> And second, did this ever work as you expect?  I tried as far back as
>> Emacs 23.3, and I see the same behavior.  Moreover, the ELisp manual
>> doesn't say anything about 'S' interrupting a trace, at least
>> according to my reading.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3257 bytes --]

bug#20074: edebug tracing can't be stopped with 'S'

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

So is this going to be fixed or what?

2015-03-11 10:30 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:

> From the manual:
>
> While executing or tracing, you can interrupt the execution by typing
> any Edebug command.  Edebug stops the program at the next stop point and
> then executes the command you typed.  For example, typing `t' during
> execution switches to trace mode at the next stop point.  You can use
> `S' to stop execution without doing anything else.
>
>
> 2015-03-11 10:28 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:
>
> ---------- Forwarded message ----------
>> From: Mario Valencia <mariovalspi@gmail.com>
>> Date: 2015-03-11 10:26 GMT-06:00
>> Subject: Re: bug#20074: edebug tracing can't be stopped with 'S'
>> To: Eli Zaretskii <eliz@gnu.org>
>>
>>
>> Its never worked and the manual implies it should. Even if the manual
>> didnt, it still should work.
>> El mar 11, 2015 10:24 a.m., "Eli Zaretskii" <eliz@gnu.org> escribió:
>>
>> > Date: Tue, 10 Mar 2015 14:42:07 -0600
>>> > From: Mario Valencia <mariovalspi@gmail.com>
>>> >
>>> > I start emacs with "runemacs -Q", on windows 8.
>>> > Then i write the following function in the scratch buffer:
>>> >
>>> > (defun forever ()
>>> > (interactive)
>>> > (while t (message "doing nothing")))
>>> >
>>> > I then press C-u C-M-x to instrument the function for debugging. Then i
>>> > do M-x forever. Then i press 't' to start tracing, and edebug starts
>>> > tracing the code correctly. However, if i press 'S' to stop, it doesn't
>>> > work. Pressing many 'S' commands repeatedly apparently only cause
>>> edebug
>>> > to evaluate the 'while' expression faster. Pressing 'q', <SPC>, 'n', do
>>> > not seem to stop edebug either, they only appear to speed up the
>>> > evaluation of the code. I have to press C-g then 'q' to return me to
>>> the
>>> > toplevel.
>>>
>>> First, I see this on GNU/Linux as well, so it's not Windows-specific,
>>> at least.
>>>
>>> And second, did this ever work as you expect?  I tried as far back as
>>> Emacs 23.3, and I see the same behavior.  Moreover, the ELisp manual
>>> doesn't say anything about 'S' interrupting a trace, at least
>>> according to my reading.
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3669 bytes --]

bug#20074: edebug tracing can't be stopped with 'S'

[Alexis]

On 2015-03-13T20:36:09+1100, Mario Valencia 
<mariovalspi@gmail.com> said:

 MV> So is this going to be fixed or what?

i'd be interested to know whether this behaviour is considered a 
bug. When i see tight code loops like this, my first thought - 
based on
experience - is: "When is the rest of the system [in this 
instance, the Emacs system] going to get a chance to do anything, 
such as read and handle input events?"

Do Emacs devs feel that Emacs should still be reasonably 
responsive in the face of such tight loops?


Alexis.

bug#20074: edebug tracing can't be stopped with 'S'

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Fri, 13 Mar 2015 21:19:57 +1100
> 
> i'd be interested to know whether this behaviour is considered a 
> bug.

Yes, it's a bug (or maybe a long-missing feature: I'm not sure it has
ever worked as intended).

> When i see tight code loops like this, my first thought - 
> based on
> experience - is: "When is the rest of the system [in this 
> instance, the Emacs system] going to get a chance to do anything, 
> such as read and handle input events?"
> 
> Do Emacs devs feel that Emacs should still be reasonably 
> responsive in the face of such tight loops?

Where do you see a tight loop during Edebug tracing?

bug#20074: edebug tracing can't be stopped with 'S'

[Alexis]

On 2015-03-13T22:07:14+1100, Eli Zaretskii <eliz@gnu.org> said:

 >> From: Alexis <flexibeast@gmail.com>

 >> Date: Fri, 13 Mar 2015 21:19:57 +1100
 >> 
 >> i'd be interested to know whether this behaviour is considered 
 >> a bug.

 EZ> Yes, it's a bug (or maybe a long-missing feature: I'm not 
 sure it EZ> has ever worked as intended).

Okay, thanks, that's useful to know. :-) (More on which below.)

 EZ> Where do you see a tight loop during Edebug tracing?

Sorry, i meant the code loop in the original bug report:

    (defun forever () 
      (interactive) (while t (message "doing nothing")))

i have occasionally accidentally written ELisp i feel is 
analogous: to wit, code that doesn't need to wait for relatively 
'slow' events, such as disk IO or user input. On those occasions, 
Emacs itself has become unresponsive to any of my attempts at 
input, and i've had to terminate the Emacs process 
itself. However, i assumed this was an instance of "So don't write 
such code then!", rather than thinking "Emacs should really still 
be responsive to user input in this situation."


Alexis.

bug#20074: edebug tracing can't be stopped with 'S'

[Stefan Monnier]

>    (defun forever ()    (interactive) (while t (message "doing nothing")))
> i have occasionally accidentally written ELisp i feel is analogous: to wit,
> code that doesn't need to wait for relatively 'slow' events, such as disk IO
> or user input.

In this case, "message" is a "slow event" which does I/O, so it's a bad
example, but I see what you mean.

> On those occasions, Emacs itself has become unresponsive to any of my
> attempts at input, and i've had to terminate the Emacs process itself.

Normally this should never happen.  In practice there are various cases
where this can happen for two reasons:
- A bug.  Some of those can be difficult to fix, tho.
- `inhibit-quit' is non-nil while running this inf-loop.  In this case,
  indeed, it's usually a bug in the Elisp code rather than in the
  C code: code that runs with inhibit-quit (e.g. code run from a timer)
  should be careful to avoid long run-times.  This isn't great, but it's
  what we have so far.


        Stefan

bug#20074: edebug tracing can't be stopped with 'S'

[Alexis]

On 2015-03-14T00:20:52+1100, Stefan Monnier 
<monnier@iro.umontreal.ca> said:

 SM> Normally this should never happen.  In practice there are 
 various SM> cases where this can happen for two reasons:
 SM> - A bug.  Some of those can be difficult to fix, tho.
 SM> - `inhibit-quit' is non-nil while running this inf-loop.  In 
 this SM> case, indeed, it's usually a bug in the Elisp code 
 rather than in SM> the C code: code that runs with inhibit-quit 
 (e.g. code run from a SM> timer) should be careful to avoid long 
 run-times.  This isn't SM> great, but it's what we have so far.

*nod* i've never set `inhibit-quit` non-nil in my own code, but i 
imagine it's more than possible that something i was calling was 
setting it non-nil, so i'll keep that in mind.

More generally, if i again encounter an unresponsive-Emacs 
scenario like the one i mentioned, i'll note it on help-gnu-emacs, 
to get others' input about whether or not it's an Emacs bug.

Thanks!


Alexis.

bug#20074: edebug tracing can't be stopped with 'S'

[Mario Valencia]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

The manual should have a note indicating this is unimplemented
functionality, and the feature should be put in the emacs to-do list. I
consider this to be high priority. Also please don't forget to include my
email as a recipient for messages in this bug.

2015-03-13 3:36 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:

> So is this going to be fixed or what?
>
> 2015-03-11 10:30 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:
>
> From the manual:
>>
>> While executing or tracing, you can interrupt the execution by typing
>> any Edebug command.  Edebug stops the program at the next stop point and
>> then executes the command you typed.  For example, typing `t' during
>> execution switches to trace mode at the next stop point.  You can use
>> `S' to stop execution without doing anything else.
>>
>>
>> 2015-03-11 10:28 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:
>>
>> ---------- Forwarded message ----------
>>> From: Mario Valencia <mariovalspi@gmail.com>
>>> Date: 2015-03-11 10:26 GMT-06:00
>>> Subject: Re: bug#20074: edebug tracing can't be stopped with 'S'
>>> To: Eli Zaretskii <eliz@gnu.org>
>>>
>>>
>>> Its never worked and the manual implies it should. Even if the manual
>>> didnt, it still should work.
>>> El mar 11, 2015 10:24 a.m., "Eli Zaretskii" <eliz@gnu.org> escribió:
>>>
>>> > Date: Tue, 10 Mar 2015 14:42:07 -0600
>>>> > From: Mario Valencia <mariovalspi@gmail.com>
>>>> >
>>>> > I start emacs with "runemacs -Q", on windows 8.
>>>> > Then i write the following function in the scratch buffer:
>>>> >
>>>> > (defun forever ()
>>>> > (interactive)
>>>> > (while t (message "doing nothing")))
>>>> >
>>>> > I then press C-u C-M-x to instrument the function for debugging. Then
>>>> i
>>>> > do M-x forever. Then i press 't' to start tracing, and edebug starts
>>>> > tracing the code correctly. However, if i press 'S' to stop, it
>>>> doesn't
>>>> > work. Pressing many 'S' commands repeatedly apparently only cause
>>>> edebug
>>>> > to evaluate the 'while' expression faster. Pressing 'q', <SPC>, 'n',
>>>> do
>>>> > not seem to stop edebug either, they only appear to speed up the
>>>> > evaluation of the code. I have to press C-g then 'q' to return me to
>>>> the
>>>> > toplevel.
>>>>
>>>> First, I see this on GNU/Linux as well, so it's not Windows-specific,
>>>> at least.
>>>>
>>>> And second, did this ever work as you expect?  I tried as far back as
>>>> Emacs 23.3, and I see the same behavior.  Moreover, the ELisp manual
>>>> doesn't say anything about 'S' interrupting a trace, at least
>>>> according to my reading.
>>>>
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4315 bytes --]

bug#20074: edebug tracing can't be stopped with 'S'

[Alan Mackenzie]

Hello, Mario.

In article <mailman.2024.1426359010.31049.bug-gnu-emacs@gnu.org> you wrote:
> [-- text/plain, encoding quoted-printable, charset: UTF-8, 72 lines --]

> The manual should have a note indicating this is unimplemented
> functionality, and the feature should be put in the emacs to-do list. I
> consider this to be high priority. Also please don't forget to include my
> email as a recipient for messages in this bug.

> 2015-03-13 3:36 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:

>> So is this going to be fixed or what?

What is happening is that while tracing, edebug is waiting for an input
event with "(sit-for 1)".  When you type the "S", sit-for pushes it onto
`unread-command-events' and returns.  Unfortunately, before calling the
recursive edit into the edebug command loop, `unread-command-events' gets
bound to nil, thus edebug doesn't see the "S".  The motivation here is
probably to separate the "outside" event queue from edebug's event queue.

Here is a fix (which Eli will probably call a workaround ;-).  In trace
mode, the top event (if any) is pulled off the "outside"
`unread-command-events' and pushed onto edebug's binding of it.



diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 1091877..f1df101 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -2397,7 +2416,15 @@ MSG is printed after `::::} '."
          (default-value 'cursor-in-non-selected-windows)))
     (unwind-protect
        (let ((cursor-in-echo-area nil)
-             (unread-command-events nil)
+             ;; (unread-command-events nil)
+             (unread-command-events
+              (if (and unread-command-events
+                       (eq edebug-execution-mode 'trace))
+                  (let ((event (car unread-command-events)))
+                    (setq unread-command-events (cdr
+                                                 unread-command-events))
+                    (list event))
+                nil))
              ;; any others??
              )
           (setq-default cursor-in-non-selected-windows t)


-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20074: edebug tracing can't be stopped with 'S'

[Alan Mackenzie]

Hello, Mario.

In article <mailman.2056.1426435627.31049.bug-gnu-emacs@gnu.org> I wrote:

> In article <mailman.2024.1426359010.31049.bug-gnu-emacs@gnu.org> you wrote:
>> [-- text/plain, encoding quoted-printable, charset: UTF-8, 72 lines --]

>> The manual should have a note indicating this is unimplemented
>> functionality, and the feature should be put in the emacs to-do list. I
>> consider this to be high priority. Also please don't forget to include my
>> email as a recipient for messages in this bug.

>> 2015-03-13 3:36 GMT-06:00 Mario Valencia <mariovalspi@gmail.com>:

>>> So is this going to be fixed or what?

> What is happening is that while tracing, edebug is waiting for an input
> event with "(sit-for 1)".  When you type the "S", sit-for pushes it onto
> `unread-command-events' and returns.  Unfortunately, before calling the
> recursive edit into the edebug command loop, `unread-command-events' gets
> bound to nil, thus edebug doesn't see the "S".  The motivation here is
> probably to separate the "outside" event queue from edebug's event queue.

> Here is a fix (which Eli will probably call a workaround ;-).  In trace
> mode, the top event (if any) is pulled off the "outside"
> `unread-command-events' and pushed onto edebug's binding of it.

Please disregard the above paragraphs and the patch in my last email.  They
were wrong.

What is actually happening is that while tracing, a "(sit-for 1)" in
edebug--display-1, when you press "S", pushes that event onto
`unread-command-events'.  However, there is nothing to trigger the entry
into the recursive edit.  Because `unread-command-events' is locally
bound in this defun, the "S" simply disappears when the enclosing `let'
form terminates.

The fix is to test the result of `sit-for', and to set `edebug-stop' when
a key was pressed.

Please try this out:

diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index 1091877..c3c4035 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -2506,7 +2528,8 @@ MSG is printed after `::::} '."
                (t (setq edebug-stop t))))
              ;; not edebug-break
              ((eq edebug-execution-mode 'trace)
-              (sit-for edebug-sit-for-seconds)) ; Force update and pause.
+              (if (not (sit-for edebug-sit-for-seconds))
+                 (setq edebug-stop t))) ; Force update and pause.
              ((eq edebug-execution-mode 'Trace-fast)
               (sit-for 0)))            ; Force update and continue.



-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20074: edebug tracing can't be stopped with 'S'

[Stefan Monnier]

> What is happening is that while tracing, edebug is waiting for an input
> event with "(sit-for 1)".  When you type the "S", sit-for pushes it onto
> `unread-command-events' and returns.  Unfortunately, before calling the
> recursive edit into the edebug command loop, `unread-command-events' gets
> bound to nil, thus edebug doesn't see the "S".  The motivation here is
> probably to separate the "outside" event queue from edebug's event queue.

Hmmm sounds like we indeed have a problem here.

> Here is a fix (which Eli will probably call a workaround ;-).  In trace
> mode, the top event (if any) is pulled off the "outside"
> `unread-command-events' and pushed onto edebug's binding of it.

I don't quite understand your fix.

AFAICT, the sit-for is inside the let-binding, so when we enter the
sit-for, unread-command-events is nil (more or less for sure) because we
just bound it to nil, and when we exit sit-for maybe
unread-command-events is non-nil, but when we then exit the let-binding
we throw away whether was added to unread-command-events.

So I don't understand how changing the entrance to the let-binding fixes
this problem, since it seems that the info gets lost when we exit the
let-binding, rather than it being hidden by the let-binding when we
enter it.

What am I missing?

Also, I wonder why the edebug.el code doesn't use the return value of
`sit-for'.


        Stefan

bug#20074: edebug tracing can't be stopped with 'S'

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 15, 2015 at 04:36:18PM -0400, Stefan Monnier wrote:
> > What is happening is that while tracing, edebug is waiting for an input
> > event with "(sit-for 1)".  When you type the "S", sit-for pushes it onto
> > `unread-command-events' and returns.  Unfortunately, before calling the
> > recursive edit into the edebug command loop, `unread-command-events' gets
> > bound to nil, thus edebug doesn't see the "S".  The motivation here is
> > probably to separate the "outside" event queue from edebug's event queue.

> Hmmm sounds like we indeed have a problem here.

> > Here is a fix (which Eli will probably call a workaround ;-).  In trace
> > mode, the top event (if any) is pulled off the "outside"
> > `unread-command-events' and pushed onto edebug's binding of it.

> I don't quite understand your fix.

Unfortunately, neither did I.  It was garbage.  Sorry for the time
wasted.  I've superseded it with a fix which actually is a fix, I hope.

> AFAICT, the sit-for is inside the let-binding, so when we enter the
> sit-for, unread-command-events is nil (more or less for sure) because we
> just bound it to nil, and when we exit sit-for maybe
> unread-command-events is non-nil, but when we then exit the let-binding
> we throw away whether was added to unread-command-events.

Exactly.  That was the bug.

> So I don't understand how changing the entrance to the let-binding fixes
> this problem, since it seems that the info gets lost when we exit the
> let-binding, rather than it being hidden by the let-binding when we
> enter it.

> What am I missing?

My next post to this bug.  ;-)

> Also, I wonder why the edebug.el code doesn't use the return value of
> `sit-for'.

It does now.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20074: edebug tracing can't be stopped with 'S'

[Stefan Monnier]

> -              (sit-for edebug-sit-for-seconds)) ; Force update and pause.
> +              (if (not (sit-for edebug-sit-for-seconds))
> +                 (setq edebug-stop t))) ; Force update and pause.

Looks much better, thanks.  I wonder if the other sit-for call should do
the same.


        Stefan

bug#20074: edebug tracing can't be stopped with 'S'

[Alan Mackenzie]

Hello, Stefan.

On Sun, Mar 15, 2015 at 11:12:52PM -0400, Stefan Monnier wrote:
> > -              (sit-for edebug-sit-for-seconds)) ; Force update and pause.
> > +              (if (not (sit-for edebug-sit-for-seconds))
> > +                 (setq edebug-stop t))) ; Force update and pause.

> Looks much better, thanks.  I wonder if the other sit-for call should do
> the same.

You mean for the one for when `edebug-execution-mode' is 'Trace-fast.  I
don't think that's the right solution.  If we did that, some "S"s from
Trace-fast would get caught by the "(if (input-pending)...)" at L+91,
and the others will get caught by the "(sit-for 0)".

Perhaps a better solution might be to move the "(if (input-pending) ...)"
to just after these two "(sit-for ..)"s, and just before the call to
edebug--recursive-edit.  Then all the testing for input events will be
done in the one place.  What that `if' form does doesn't seem critical to
the functionality, apart from setting `edebug-stop' to t -
"(edebug-stop)" merely displays "STOP" in the echo area.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#20074: edebug tracing can't be stopped with 'S'

[Stefan Monnier]

> Perhaps a better solution might be to move the "(if (input-pending) ...)"
> to just after these two "(sit-for ..)"s, and just before the call to
> edebug--recursive-edit.

Sounds right.


        Stefan

bug#20074: edebug tracing can't be stopped with 'S'

[Alan Mackenzie]

Bug fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).