* Making debugging possible on expressions executed from ielm
@ 2018-01-13 9:22 Jarosław Rzeszótko
2018-01-15 17:23 ` Stefan Monnier
2018-01-15 19:22 ` Jarosław Rzeszótko
0 siblings, 2 replies; 8+ messages in thread
From: Jarosław Rzeszótko @ 2018-01-13 9:22 UTC (permalink / raw)
To: emacs-devel@gnu.org
[-- Attachment #1.1: Type: text/plain, Size: 1682 bytes --]
I attach a patch for ielm.el that makes it possible to enter the debugger
when executing expressions in ielm, and that makes ielm respect the
debug-on-error and debug-on-exit flags.
I guess that possibly the reason that was not originally done is that it is
not obvious how to restore ielm to a usable state after the debugger has
been entered. My patch makes use of the fact that unwind-protect unwind
forms are still executed when user resumes execution from the debugger
after an error.
Without the patch, ielm wraps the evaluation of the expression given by the
user in a condition case, and in case of an error, or exit, displays an
appropriate message in its buffer, right under the evaluated expression,
regardless of debug-on-error and debug-on-exit.
With the patch, the message that ielm displays in its buffer will be a
generic error message regardless if there was an error in the evaluated
form, or a quit. However:
- if debug-on-error is t, emacs will enter the debugger and show a stack
trace, just like with almost any other evaluation method. When the user
continues the execution from the debugger, ielm will correctly resume
execution
- if debug-on-error is nil, emacs will display the specific error in the
minibuffer anyway
Similar things are true for debug-on-quit.
I think this is an improvement over the current state of affairs. Of course
ideally I would like to preserve the "nice" message in ielm buffer and make
the improvements I made, but emacs does not seem to make it possible to do
some handling of an error and then to re-raise it while preserving the
original stack trace.
Cheers,
Jarosław Rzeszótko
[-- Attachment #1.2: Type: text/html, Size: 1936 bytes --]
[-- Attachment #2: ielm-debug-on-error.el.patch --]
[-- Type: text/x-patch, Size: 12410 bytes --]
diff --git a/lisp/ielm.el b/lisp/ielm.el
index fb285e80f6..13bb4693cd 100644
--- a/lisp/ielm.el
+++ b/lisp/ielm.el
@@ -353,113 +353,117 @@ nonempty, then flushes the buffer."
(output "") ; result to display
(wbuf ielm-working-buffer) ; current buffer after evaluation
(pmark (ielm-pm)))
- (unless (ielm-is-whitespace-or-comment string)
- (condition-case err
- (let ((rout (read-from-string string)))
- (setq form (car rout)
- pos (cdr rout)))
- (error (setq result (error-message-string err))
- (setq error-type "Read error")))
- (unless error-type
- ;; Make sure working buffer has not been killed
- (if (not (buffer-name ielm-working-buffer))
- (setq result "Working buffer has been killed"
- error-type "IELM Error"
- wbuf (current-buffer))
- (if (ielm-is-whitespace-or-comment (substring string pos))
- ;; To correctly handle the ielm-local variables *,
- ;; ** and ***, we need a temporary buffer to be
- ;; current at entry to the inner of the next two let
- ;; forms. We need another temporary buffer to exit
- ;; that same let. To avoid problems, neither of
- ;; these buffers should be alive during the
- ;; evaluation of form.
- (let* ((*1 *)
- (*2 **)
- (*3 ***)
- (active-process (ielm-process))
- (old-standard-output standard-output)
- new-standard-output
- ielm-temp-buffer)
- (set-match-data ielm-match-data)
- (save-excursion
- (with-temp-buffer
- (condition-case err
- (unwind-protect
- ;; The next let form creates default
- ;; bindings for *, ** and ***. But
- ;; these default bindings are
- ;; identical to the ielm-local
- ;; bindings. Hence, during the
- ;; evaluation of form, the
- ;; ielm-local values are going to be
- ;; used in all buffers except for
- ;; other ielm buffers, which override
- ;; them. Normally, the variables *1,
- ;; *2 and *3 also have default
- ;; bindings, which are not overridden.
- (let ((* *1)
- (** *2)
- (*** *3))
- (when (eq standard-output t)
- (setf new-standard-output
- (ielm-standard-output-impl
- active-process))
- (setf standard-output new-standard-output))
- (kill-buffer (current-buffer))
- (set-buffer wbuf)
- (setq result
- (eval form lexical-binding))
- (setq wbuf (current-buffer))
- (setq
- ielm-temp-buffer
- (generate-new-buffer " *ielm-temp*"))
- (set-buffer ielm-temp-buffer))
- (when ielm-temp-buffer
- (kill-buffer ielm-temp-buffer))
- (when (eq new-standard-output standard-output)
- (ignore-errors
- (funcall standard-output t))
- (setf standard-output old-standard-output)))
- (error (setq result (error-message-string err))
- (setq error-type "Eval error"))
- (quit (setq result "Quit during evaluation")
- (setq error-type "Eval error")))))
- (setq ielm-match-data (match-data)))
- (setq error-type "IELM error")
- (setq result "More than one sexp in input"))))
-
- ;; If the eval changed the current buffer, mention it here
- (unless (eq wbuf ielm-working-buffer)
- (message "current buffer is now: %s" wbuf)
- (setq ielm-working-buffer wbuf))
-
- (goto-char pmark)
- (unless error-type
- (condition-case nil
- ;; Self-referential objects cause loops in the printer, so
- ;; trap quits here. May as well do errors, too
- (unless for-effect
- (setq output (concat output (pp-to-string result)
- (let ((str (eval-expression-print-format result)))
- (if str (propertize str 'font-lock-face 'shadow))))))
- (error (setq error-type "IELM Error")
- (setq result "Error during pretty-printing (bug in pp)"))
- (quit (setq error-type "IELM Error")
- (setq result "Quit during pretty-printing"))))
- (if error-type
+ (unwind-protect
+ (progn
+ (unless (ielm-is-whitespace-or-comment string)
+ (condition-case err
+ (let ((rout (read-from-string string)))
+ (setq form (car rout)
+ pos (cdr rout)))
+ (error (setq result (error-message-string err))
+ (setq error-type "Read error")))
+ (unless error-type
+ ;; Make sure working buffer has not been killed
+ (if (not (buffer-name ielm-working-buffer))
+ (setq result "Working buffer has been killed"
+ error-type "IELM Error"
+ wbuf (current-buffer))
+ (if (ielm-is-whitespace-or-comment (substring string pos))
+ ;; To correctly handle the ielm-local variables *,
+ ;; ** and ***, we need a temporary buffer to be
+ ;; current at entry to the inner of the next two let
+ ;; forms. We need another temporary buffer to exit
+ ;; that same let. To avoid problems, neither of
+ ;; these buffers should be alive during the
+ ;; evaluation of form.
+ (let* ((*1 *)
+ (*2 **)
+ (*3 ***)
+ (active-process (ielm-process))
+ (old-standard-output standard-output)
+ new-standard-output
+ ielm-temp-buffer)
+ (set-match-data ielm-match-data)
+ (save-excursion
+ (with-temp-buffer
+ (unwind-protect
+ ;; The next let form creates default
+ ;; bindings for *, ** and ***. But
+ ;; these default bindings are
+ ;; identical to the ielm-local
+ ;; bindings. Hence, during the
+ ;; evaluation of form, the
+ ;; ielm-local values are going to be
+ ;; used in all buffers except for
+ ;; other ielm buffers, which override
+ ;; them. Normally, the variables *1,
+ ;; *2 and *3 also have default
+ ;; bindings, which are not overridden.
+ (let ((* *1)
+ (** *2)
+ (*** *3))
+ (setq result nil)
+ (when (eq standard-output t)
+ (setf new-standard-output
+ (ielm-standard-output-impl
+ active-process))
+ (setf standard-output new-standard-output))
+ (kill-buffer (current-buffer))
+ (set-buffer wbuf)
+ ;; Will immediately get
+ ;; overwritten, but only if eval
+ ;; does not throw an error
+ (setq error-type "Eval error")
+ (setq result
+ (eval form lexical-binding))
+ (setq error-type nil)
+ (setq wbuf (current-buffer))
+ (setq
+ ielm-temp-buffer
+ (generate-new-buffer " *ielm-temp*"))
+ (set-buffer ielm-temp-buffer))
+ (when ielm-temp-buffer
+ (kill-buffer ielm-temp-buffer))
+ (when (eq new-standard-output standard-output)
+ (ignore-errors
+ (funcall standard-output t))
+ (setf standard-output old-standard-output)))))
+ (setq ielm-match-data (match-data)))
+ (setq error-type "IELM error")
+ (setq result "More than one sexp in input"))))
+
+ ;; If the eval changed the current buffer, mention it here
+ (unless (eq wbuf ielm-working-buffer)
+ (message "current buffer is now: %s" wbuf)
+ (setq ielm-working-buffer wbuf))
+
+ (goto-char pmark)
+ (unless error-type
+ (condition-case nil
+ ;; Self-referential objects cause loops in the printer, so
+ ;; trap quits here. May as well do errors, too
+ (unless for-effect
+ (setq output (concat output (pp-to-string result)
+ (let ((str (eval-expression-print-format result)))
+ (if str (propertize str 'font-lock-face 'shadow))))))
+ (error (setq error-type "IELM Error")
+ (setq result "Error during pretty-printing (bug in pp)"))
+ (quit (setq error-type "IELM Error")
+ (setq result "Quit during pretty-printing"))))))
(progn
- (when ielm-noisy (ding))
- (setq output (concat output "*** " error-type " *** "))
- (setq output (concat output result)))
- ;; There was no error, so shift the *** values
- (setq *** **)
- (setq ** *)
- (setq * result))
- (when (or (not for-effect) (not (equal output "")))
- (setq output (concat output "\n"))))
- (setq output (concat output ielm-prompt-internal))
- (comint-output-filter (ielm-process) output)))
+ (if error-type
+ (progn
+ (when ielm-noisy (ding))
+ (setq output (concat output "*** " error-type " *** "))
+ (setq output (concat output result)))
+ ;; There was no error, so shift the *** values
+ (setq *** **)
+ (setq ** *)
+ (setq * result))
+ (when (or (not for-effect) (not (equal output "")))
+ (setq output (concat output "\n"))))
+ (setq output (concat output ielm-prompt-internal))
+ (comint-output-filter (ielm-process) output))))
;;; Process and marker utilities
@@ -517,9 +521,6 @@ causes output to be directed to the ielm buffer.
set to a different value during evaluation. You can use (princ
VALUE) or (pp VALUE) to write to the ielm buffer.
-Expressions evaluated by IELM are not subject to `debug-on-quit' or
-`debug-on-error'.
-
The behavior of IELM may be customized with the following variables:
* To stop beeping on error, set `ielm-noisy' to nil.
* If you don't like the prompt, you can change it by setting `ielm-prompt'.
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-13 9:22 Making debugging possible on expressions executed from ielm Jarosław Rzeszótko
@ 2018-01-15 17:23 ` Stefan Monnier
2018-01-15 19:22 ` Jarosław Rzeszótko
1 sibling, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2018-01-15 17:23 UTC (permalink / raw)
To: emacs-devel
> - if debug-on-error is t, emacs will enter the debugger and show a stack
> trace, just like with almost any other evaluation method. When the user
> continues the execution from the debugger, ielm will correctly resume
> execution
Have you tried to use `condition-case-unless-debug`?
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-13 9:22 Making debugging possible on expressions executed from ielm Jarosław Rzeszótko
2018-01-15 17:23 ` Stefan Monnier
@ 2018-01-15 19:22 ` Jarosław Rzeszótko
2018-01-15 21:59 ` Stefan Monnier
` (2 more replies)
1 sibling, 3 replies; 8+ messages in thread
From: Jarosław Rzeszótko @ 2018-01-15 19:22 UTC (permalink / raw)
To: emacs-devel@gnu.org
[-- Attachment #1.1: Type: text/plain, Size: 2056 bytes --]
Stefan,
I did not know about condition-case-unless-debug, it indeed does make
debugging possible with a simpler change and without any side effects. I
attach the patch.
Cheers,
Jarosław Rzeszótko
On Sat, Jan 13, 2018 at 10:22 AM, Jarosław Rzeszótko <jrzeszotko@gmail.com>
wrote:
> I attach a patch for ielm.el that makes it possible to enter the debugger
> when executing expressions in ielm, and that makes ielm respect the
> debug-on-error and debug-on-exit flags.
>
> I guess that possibly the reason that was not originally done is that it
> is not obvious how to restore ielm to a usable state after the debugger has
> been entered. My patch makes use of the fact that unwind-protect unwind
> forms are still executed when user resumes execution from the debugger
> after an error.
>
> Without the patch, ielm wraps the evaluation of the expression given by
> the user in a condition case, and in case of an error, or exit, displays an
> appropriate message in its buffer, right under the evaluated expression,
> regardless of debug-on-error and debug-on-exit.
>
> With the patch, the message that ielm displays in its buffer will be a
> generic error message regardless if there was an error in the evaluated
> form, or a quit. However:
>
> - if debug-on-error is t, emacs will enter the debugger and show a stack
> trace, just like with almost any other evaluation method. When the user
> continues the execution from the debugger, ielm will correctly resume
> execution
>
> - if debug-on-error is nil, emacs will display the specific error in the
> minibuffer anyway
>
> Similar things are true for debug-on-quit.
>
> I think this is an improvement over the current state of affairs. Of
> course ideally I would like to preserve the "nice" message in ielm buffer
> and make the improvements I made, but emacs does not seem to make it
> possible to do some handling of an error and then to re-raise it while
> preserving the original stack trace.
>
> Cheers,
> Jarosław Rzeszótko
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 2576 bytes --]
[-- Attachment #2: ielm-with-debugger.el.diff --]
[-- Type: text/plain, Size: 1777 bytes --]
diff --git a/lisp/ielm.el b/lisp/ielm.el
index fb285e80f6..30d6515e69 100644
--- a/lisp/ielm.el
+++ b/lisp/ielm.el
@@ -354,7 +354,7 @@ nonempty, then flushes the buffer."
(wbuf ielm-working-buffer) ; current buffer after evaluation
(pmark (ielm-pm)))
(unless (ielm-is-whitespace-or-comment string)
- (condition-case err
+ (condition-case-unless-debug err
(let ((rout (read-from-string string)))
(setq form (car rout)
pos (cdr rout)))
@@ -384,7 +384,7 @@ nonempty, then flushes the buffer."
(set-match-data ielm-match-data)
(save-excursion
(with-temp-buffer
- (condition-case err
+ (condition-case-unless-debug err
(unwind-protect
;; The next let form creates default
;; bindings for *, ** and ***. But
@@ -436,7 +436,7 @@ nonempty, then flushes the buffer."
(goto-char pmark)
(unless error-type
- (condition-case nil
+ (condition-case-unless-debug nil
;; Self-referential objects cause loops in the printer, so
;; trap quits here. May as well do errors, too
(unless for-effect
@@ -517,9 +517,6 @@ causes output to be directed to the ielm buffer.
set to a different value during evaluation. You can use (princ
VALUE) or (pp VALUE) to write to the ielm buffer.
-Expressions evaluated by IELM are not subject to `debug-on-quit' or
-`debug-on-error'.
-
The behavior of IELM may be customized with the following variables:
* To stop beeping on error, set `ielm-noisy' to nil.
* If you don't like the prompt, you can change it by setting `ielm-prompt'.
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-15 19:22 ` Jarosław Rzeszótko
@ 2018-01-15 21:59 ` Stefan Monnier
2018-01-16 6:42 ` Jarosław Rzeszótko
2018-01-19 19:14 ` Jarosław Rzeszótko
2018-01-20 17:55 ` Stefan Monnier
2 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2018-01-15 21:59 UTC (permalink / raw)
To: emacs-devel
> I did not know about condition-case-unless-debug, it indeed does make
> debugging possible with a simpler change and without any side effects.
> I attach the patch.
Have you verified that IELM stays usable after such an error?
Are all 3 hunks necessary?
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-15 21:59 ` Stefan Monnier
@ 2018-01-16 6:42 ` Jarosław Rzeszótko
0 siblings, 0 replies; 8+ messages in thread
From: Jarosław Rzeszótko @ 2018-01-16 6:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]
On Mon, Jan 15, 2018 at 10:59 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> > I did not know about condition-case-unless-debug, it indeed does make
> > debugging possible with a simpler change and without any side effects.
> > I attach the patch.
>
> Have you verified that IELM stays usable after such an error?
>
In the tests I was able to invent, yes. If you press c from the debugger to
continue execution the IELM error message and a new prompt appear as
usually, and evaluating new expressions in IELM still works fine. I was
mostly interested in seeing the stack trace in the debugger, and I am not a
power user of the Emacs debugger, but I did also try evaluating some
expressions from the debugger, stepping through etc., it all seemed to work
fine. You do see all the ielm internal functions in the stack trace, with
the stack trace of your expression on top. This is no different from e.g.
evaluating an expression with M-: though, where you also enter the debugger
in the context of some Emacs internals.
I tried to find some trace in the version control history of why the
limitation of not respecting debug-on-error could possibly be there, I did
not find anything though. The comment about not respecting debug-on-error
and debug-on-quit is in ielm.el from 1994:
https://github.com/emacs-mirror/emacs/commit/813f532d2f0d18dcda7d93be2c6cd841815ff8b8#diff-63abff285057c34e375ed9bb9f2f0199R302
> Are all 3 hunks necessary?
>
The middle one is the most important as it covers evaluation of the form
that was read in. However in the other two cases, of an read error and a
pretty printing error, IELM also will show an error before emitting next
prompt, and I think you plausibly could be willing to debug the error, or
at least examine the stack trace.
I was giving some thought to having ielm-debug-on-error and
ielm-debug-on-quit variables, initializing them to debug-on-error and
debug-on-quit default values, and having the ielm-* versions take
precedence, so that you can customize ielm to behave differently than the
rest of Emacs. Personally though I think it only would make sense if there
were some pitfalls or quirks in debugging from IELM, and right now I don't
see any.
Cheers,
Jarosław Rzeszótko
[-- Attachment #2: Type: text/html, Size: 3057 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-15 19:22 ` Jarosław Rzeszótko
2018-01-15 21:59 ` Stefan Monnier
@ 2018-01-19 19:14 ` Jarosław Rzeszótko
2018-01-19 19:58 ` Eli Zaretskii
2018-01-20 17:55 ` Stefan Monnier
2 siblings, 1 reply; 8+ messages in thread
From: Jarosław Rzeszótko @ 2018-01-19 19:14 UTC (permalink / raw)
To: emacs-devel@gnu.org
[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]
Any chances of getting this patch committed?
Thanks and cheers,
Jarosław Rzeszótko
On Mon, Jan 15, 2018 at 8:22 PM, Jarosław Rzeszótko <jrzeszotko@gmail.com>
wrote:
> Stefan,
>
> I did not know about condition-case-unless-debug, it indeed does make
> debugging possible with a simpler change and without any side effects. I
> attach the patch.
>
> Cheers,
> Jarosław Rzeszótko
>
> On Sat, Jan 13, 2018 at 10:22 AM, Jarosław Rzeszótko <jrzeszotko@gmail.com
> > wrote:
>
>> I attach a patch for ielm.el that makes it possible to enter the debugger
>> when executing expressions in ielm, and that makes ielm respect the
>> debug-on-error and debug-on-exit flags.
>>
>> I guess that possibly the reason that was not originally done is that it
>> is not obvious how to restore ielm to a usable state after the debugger has
>> been entered. My patch makes use of the fact that unwind-protect unwind
>> forms are still executed when user resumes execution from the debugger
>> after an error.
>>
>> Without the patch, ielm wraps the evaluation of the expression given by
>> the user in a condition case, and in case of an error, or exit, displays an
>> appropriate message in its buffer, right under the evaluated expression,
>> regardless of debug-on-error and debug-on-exit.
>>
>> With the patch, the message that ielm displays in its buffer will be a
>> generic error message regardless if there was an error in the evaluated
>> form, or a quit. However:
>>
>> - if debug-on-error is t, emacs will enter the debugger and show a stack
>> trace, just like with almost any other evaluation method. When the user
>> continues the execution from the debugger, ielm will correctly resume
>> execution
>>
>> - if debug-on-error is nil, emacs will display the specific error in the
>> minibuffer anyway
>>
>> Similar things are true for debug-on-quit.
>>
>> I think this is an improvement over the current state of affairs. Of
>> course ideally I would like to preserve the "nice" message in ielm buffer
>> and make the improvements I made, but emacs does not seem to make it
>> possible to do some handling of an error and then to re-raise it while
>> preserving the original stack trace.
>>
>> Cheers,
>> Jarosław Rzeszótko
>>
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 3129 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-19 19:14 ` Jarosław Rzeszótko
@ 2018-01-19 19:58 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2018-01-19 19:58 UTC (permalink / raw)
To: Jarosław Rzeszótko; +Cc: emacs-devel
> From: Jarosław Rzeszótko <jrzeszotko@gmail.com>
> Date: Fri, 19 Jan 2018 20:14:15 +0100
>
> Any chances of getting this patch committed?
Yes. But 3 days is too few to expect a response in all cases, so
please wait for a few more days, and then ping if you see no
responses.
Thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Making debugging possible on expressions executed from ielm
2018-01-15 19:22 ` Jarosław Rzeszótko
2018-01-15 21:59 ` Stefan Monnier
2018-01-19 19:14 ` Jarosław Rzeszótko
@ 2018-01-20 17:55 ` Stefan Monnier
2 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2018-01-20 17:55 UTC (permalink / raw)
To: emacs-devel
> I did not know about condition-case-unless-debug, it indeed does make
> debugging possible with a simpler change and without any side effects.
> I attach the patch.
Thanks. I installed it, but not the part that surrounds reading and
pretty printing: these would be used to debug IELM itself rather than
the code provided by the user to ielm.
I'm not 100% opposed to it, but at least my experience with debugging
errors in the printer leads me to think that such errors are hard to
debug in the debugger anyway (because they also affect the debugger), so
I went with a more conservative patch which only changes the part which
I positively know is useful (because I've been using a similar tho more
convoluted patch for years (had completely forgotten about it)).
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-01-20 17:55 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-13 9:22 Making debugging possible on expressions executed from ielm Jarosław Rzeszótko
2018-01-15 17:23 ` Stefan Monnier
2018-01-15 19:22 ` Jarosław Rzeszótko
2018-01-15 21:59 ` Stefan Monnier
2018-01-16 6:42 ` Jarosław Rzeszótko
2018-01-19 19:14 ` Jarosław Rzeszótko
2018-01-19 19:58 ` Eli Zaretskii
2018-01-20 17:55 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).