* bug#20074: edebug tracing can't be stopped with 'S'
@ 2015-03-10 20:42 Mario Valencia
2015-03-11 16:24 ` Eli Zaretskii
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Mario Valencia @ 2015-03-10 20:42 UTC (permalink / raw)
To: 20074
[-- 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 --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#20074: edebug tracing can't be stopped with 'S'
2015-03-10 20:42 bug#20074: edebug tracing can't be stopped with 'S' Mario Valencia
@ 2015-03-11 16:24 ` Eli Zaretskii
[not found] ` <CA+3HrJXsgWHQG_6zk2vNXzEaqT8w-5-cw26fkLYH0xQXmk=nSQ@mail.gmail.com>
[not found] ` <mailman.2024.1426359010.31049.bug-gnu-emacs@gnu.org>
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2015-03-11 16:24 UTC (permalink / raw)
To: Mario Valencia; +Cc: 20074
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <mailman.2024.1426359010.31049.bug-gnu-emacs@gnu.org>]
* bug#20074: edebug tracing can't be stopped with 'S'
[not found] ` <mailman.2024.1426359010.31049.bug-gnu-emacs@gnu.org>
@ 2015-03-15 16:06 ` Alan Mackenzie
2015-03-15 20:36 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Alan Mackenzie @ 2015-03-15 16:06 UTC (permalink / raw)
To: 20074; +Cc: Mario Valencia
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).
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#20074: edebug tracing can't be stopped with 'S'
2015-03-15 16:06 ` Alan Mackenzie
@ 2015-03-15 20:36 ` Stefan Monnier
2015-03-15 21:31 ` Alan Mackenzie
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2015-03-15 20:36 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 20074, Mario Valencia
> 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#20074: edebug tracing can't be stopped with 'S'
2015-03-15 20:36 ` Stefan Monnier
@ 2015-03-15 21:31 ` Alan Mackenzie
0 siblings, 0 replies; 19+ messages in thread
From: Alan Mackenzie @ 2015-03-15 21:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 20074, Mario Valencia
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).
^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <mailman.2056.1426435627.31049.bug-gnu-emacs@gnu.org>]
* bug#20074: edebug tracing can't be stopped with 'S'
[not found] ` <mailman.2056.1426435627.31049.bug-gnu-emacs@gnu.org>
@ 2015-03-15 19:55 ` Alan Mackenzie
2015-03-16 3:12 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Alan Mackenzie @ 2015-03-15 19:55 UTC (permalink / raw)
To: 20074; +Cc: Mario Valencia
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).
^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#20074: edebug tracing can't be stopped with 'S'
2015-03-15 19:55 ` Alan Mackenzie
@ 2015-03-16 3:12 ` Stefan Monnier
2015-03-16 11:38 ` Alan Mackenzie
0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2015-03-16 3:12 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: 20074, Mario Valencia
> - (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
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#20074: edebug tracing can't be stopped with 'S'
2015-03-16 3:12 ` Stefan Monnier
@ 2015-03-16 11:38 ` Alan Mackenzie
2015-03-16 13:11 ` Stefan Monnier
0 siblings, 1 reply; 19+ messages in thread
From: Alan Mackenzie @ 2015-03-16 11:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 20074, Mario Valencia
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).
^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <mailman.1823.1426020966.31049.bug-gnu-emacs@gnu.org>]
end of thread, other threads:[~2015-03-16 22:21 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-10 20:42 bug#20074: edebug tracing can't be stopped with 'S' Mario Valencia
2015-03-11 16:24 ` Eli Zaretskii
[not found] ` <CA+3HrJXsgWHQG_6zk2vNXzEaqT8w-5-cw26fkLYH0xQXmk=nSQ@mail.gmail.com>
2015-03-11 16:28 ` bug#20074: Fwd: " Mario Valencia
2015-03-11 16:30 ` Mario Valencia
2015-03-13 9:36 ` Mario Valencia
2015-03-13 10:19 ` Alexis
2015-03-13 11:07 ` Eli Zaretskii
2015-03-13 11:37 ` Alexis
2015-03-13 13:20 ` Stefan Monnier
2015-03-13 14:02 ` Alexis
2015-03-14 18:49 ` Mario Valencia
[not found] ` <mailman.2024.1426359010.31049.bug-gnu-emacs@gnu.org>
2015-03-15 16:06 ` Alan Mackenzie
2015-03-15 20:36 ` Stefan Monnier
2015-03-15 21:31 ` Alan Mackenzie
[not found] ` <mailman.2056.1426435627.31049.bug-gnu-emacs@gnu.org>
2015-03-15 19:55 ` Alan Mackenzie
2015-03-16 3:12 ` Stefan Monnier
2015-03-16 11:38 ` Alan Mackenzie
2015-03-16 13:11 ` Stefan Monnier
[not found] ` <mailman.1823.1426020966.31049.bug-gnu-emacs@gnu.org>
2015-03-16 22:21 ` Alan Mackenzie
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.