* bug#9463: 24.0.50; Errors should not be continuable @ 2011-09-08 12:01 Helmut Eller 2011-09-08 13:31 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-08 12:01 UTC (permalink / raw) To: 9463 emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' enters the debugger. Pressing c somehow manages to continue. That make no sense to me. The debugger should instead not continue and say that errors are not continuable. In GNU Emacs 24.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2011-09-05 on ix Windowing system distributor `The X.Org Foundation', version 11.0.10707000 configured using `configure '--enable-asserts' '--enable-checking' '--with-gif=no' '--with-gnutls=no' 'CFLAGS=-g3 -O0'' ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-08 12:01 bug#9463: 24.0.50; Errors should not be continuable Helmut Eller @ 2011-09-08 13:31 ` Stefan Monnier 2011-09-08 18:13 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2011-09-08 13:31 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 > emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' > enters the debugger. Pressing c somehow manages to continue. That make > no sense to me. The debugger should instead not continue and say > that errors are not continuable. "c" in errors now "continues" in the sense of "do what would have happened if the debugger had not been called". I.e. it will actually signal the error which can then be caught by condition-cases further up the stack, .... I.e. it's very similar to what happens with "q", but is often cleaner. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-08 13:31 ` Stefan Monnier @ 2011-09-08 18:13 ` Helmut Eller 2011-09-09 2:23 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-08 18:13 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-08 13:31] writes: >> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' >> enters the debugger. Pressing c somehow manages to continue. That make >> no sense to me. The debugger should instead not continue and say >> that errors are not continuable. > > "c" in errors now "continues" in the sense of "do what would have > happened if the debugger had not been called". I.e. it will actually > signal the error which can then be caught by condition-cases further up > the stack, .... I.e. it's very similar to what happens with "q", but is > often cleaner. I think the "do what would have happened if the debugger had not been called" thing should be a different command, like resignal or abort. c should only continue from truly continuable situations, like breakpoints. Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-08 18:13 ` Helmut Eller @ 2011-09-09 2:23 ` Stefan Monnier 2011-09-09 6:53 ` Helmut Eller 2011-09-09 7:10 ` Eli Zaretskii 0 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2011-09-09 2:23 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 >>> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' >>> enters the debugger. Pressing c somehow manages to continue. That make >>> no sense to me. The debugger should instead not continue and say >>> that errors are not continuable. >> >> "c" in errors now "continues" in the sense of "do what would have >> happened if the debugger had not been called". I.e. it will actually >> signal the error which can then be caught by condition-cases further up >> the stack, .... I.e. it's very similar to what happens with "q", but is >> often cleaner. > I think the "do what would have happened if the debugger had not been > called" thing should be a different command, like resignal or abort. Why? When the debugger is called in a non-error case, the "c" does just that "do whatever would have happened if the debug call had no taken place". > c should only continue from truly continuable situations, like > breakpoints. Again: why? Stefan PS: The change you seem to dislike is a bug-fix in my opinion, and it has fixed a few real problems (e.g. when you enter the debugger from within a minibuffer, you can now continue your minibuffer operation, whereas earlier you could only abort back to the top-level). ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 2:23 ` Stefan Monnier @ 2011-09-09 6:53 ` Helmut Eller 2011-09-09 14:07 ` Stefan Monnier 2011-09-09 7:10 ` Eli Zaretskii 1 sibling, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-09 6:53 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-09 02:23] writes: >>>> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' >>>> enters the debugger. Pressing c somehow manages to continue. That make >>>> no sense to me. The debugger should instead not continue and say >>>> that errors are not continuable. >>> >>> "c" in errors now "continues" in the sense of "do what would have >>> happened if the debugger had not been called". I.e. it will actually >>> signal the error which can then be caught by condition-cases further up >>> the stack, .... I.e. it's very similar to what happens with "q", but is >>> often cleaner. >> I think the "do what would have happened if the debugger had not been >> called" thing should be a different command, like resignal or abort. > > Why? 1. Why not? > When the debugger is called in a non-error case, the "c" does just > that "do whatever would have happened if the debug call had no taken place". 2. it's an incompatible change 3. it's frustrating when people introduce DWIM-ish features when my expectations are completely different > >> c should only continue from truly continuable situations, like >> breakpoints. > > Again: why? 4. it's easy to accidentally press c when using d and c multiple times 5. I have already lost valuable information (and time) because of this too eager stack unwinding. 6. there is nothing wrong with the traditional distinction between continuable and non-continuable situations > > > Stefan > > PS: The change you seem to dislike is a bug-fix in my opinion, and it has > fixed a few real problems It introduced a new bug: r can now be used in every situation. > (e.g. when you enter the debugger from within > a minibuffer, you can now continue your minibuffer operation, whereas > earlier you could only abort back to the top-level). You could do that just as well with a separate resignal command. Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 6:53 ` Helmut Eller @ 2011-09-09 14:07 ` Stefan Monnier 2011-09-09 16:37 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2011-09-09 14:07 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 >>> I think the "do what would have happened if the debugger had not been >>> called" thing should be a different command, like resignal or abort. >> Why? > 1. Why not? The question is "why" and not "why not": the current behavior is the logical result of writing simple and the clean code. Doing something special when the error is "uncontinuable" requires extra code, so it needs to be justified by a good reason. >> When the debugger is called in a non-error case, the "c" does just >> that "do whatever would have happened if the debug call had no taken place". > 2. it's an incompatible change It's a user-visible change, yes (it doesn't break any code, AFAIK, so it's not what we usually consider as "incompatible"). > 3. it's frustrating when people introduce DWIM-ish features when my > expectations are completely different. There's nothing DWIMish at all about it. >>> c should only continue from truly continuable situations, like >>> breakpoints. >> Again: why? > 4. it's easy to accidentally press c when using d and c multiple times Could you describe a scenario where this would be a problem? > 5. I have already lost valuable information (and time) because of this > too eager stack unwinding. I guess the previous scenario would be the same as this one, but if not, could you describe the scenario where you lost info because of this? > 6. there is nothing wrong with the traditional distinction between > continuable and non-continuable situations. The Elisp debugger does not *catch* signals: it just gets invoked at various points of the execution so you can examine the state. >> PS: The change you seem to dislike is a bug-fix in my opinion, and it has >> fixed a few real problems > It introduced a new bug: r can now be used in every situation. It does extend an old bug to more situations, but it's hardly a new bug. The documentation of debugger-return-value already states very clearly that it's not always useful to use it. >> (e.g. when you enter the debugger from within a minibuffer, you can >> now continue your minibuffer operation, whereas earlier you could >> only abort back to the top-level). > You could do that just as well with a separate resignal command. From an implementation point of view, at least, calling it "resignal" would be incorrect. All in all, I think what you're asking is for the debugger to be informed of the situation in which it is invoked (e.g. because of a signal, or because of an explicit call, when entering a function, when exiting a function, ...) so that commands like `r' can tell whether they'll be useful and so that we can provide a new command "continue only if this was not a signal" that would behave somewhat like the old "continue" (tho more cleanly since it would burp right away instead of doing the previous dance of first continuing, then having the C-level code figure out that you're trying to continue after a signal and hence re-enter the debugger with a new error). Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 14:07 ` Stefan Monnier @ 2011-09-09 16:37 ` Helmut Eller 2011-09-09 21:44 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-09 16:37 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-09 14:07] writes: >>>> I think the "do what would have happened if the debugger had not been >>>> called" thing should be a different command, like resignal or abort. >>> Why? >> 1. Why not? > > The question is "why" and not "why not": the current behavior is the > logical result of writing simple and the clean code. Doing something > special when the error is "uncontinuable" requires extra code, so it > needs to be justified by a good reason. > >>> When the debugger is called in a non-error case, the "c" does just >>> that "do whatever would have happened if the debug call had no taken place". >> 2. it's an incompatible change > > It's a user-visible change, yes (it doesn't break any code, AFAIK, so > it's not what we usually consider as "incompatible"). >> 3. it's frustrating when people introduce DWIM-ish features when my >> expectations are completely different. > > There's nothing DWIMish at all about it. That's in the eye beholder. c shouldn't "do what would have happened if the debugger had not been called" unless I say so. >>>> c should only continue from truly continuable situations, like >>>> breakpoints. >>> Again: why? >> 4. it's easy to accidentally press c when using d and c multiple times > > Could you describe a scenario where this would be a problem? Let's assume we are hunting down some annoying bug. The debugger just popped up and we execute the sequence: d c d c c c c. The last 4 c are needed for a loop that has a call to debug. Now we are at a moderately interesting place, lets continue: d c. The last c hits an error but we are in a hurry and don't see it. Pressing c again suddenly brings us back to top-level. Duh! The stack is gone. >> 5. I have already lost valuable information (and time) because of this >> too eager stack unwinding. > > I guess the previous scenario would be the same as this one, but if not, > could you describe the scenario where you lost info because of this? I load some data from the network into a temporary buffer for parsing. The parser has a bug and invokes the debugger. Pressing c unwinds the stack and kills the temporary buffer. The input from the network is lost. >> 6. there is nothing wrong with the traditional distinction between >> continuable and non-continuable situations. > > The Elisp debugger does not *catch* signals: it just gets invoked at > various points of the execution so you can examine the state. >>> PS: The change you seem to dislike is a bug-fix in my opinion, and it has >>> fixed a few real problems >> It introduced a new bug: r can now be used in every situation. > > It does extend an old bug to more situations, but it's hardly > a new bug. Interesting way to put it. > The documentation of debugger-return-value already states > very clearly that it's not always useful to use it. >>> (e.g. when you enter the debugger from within a minibuffer, you can >>> now continue your minibuffer operation, whereas earlier you could >>> only abort back to the top-level). >> You could do that just as well with a separate resignal command. > > From an implementation point of view, at least, calling it "resignal" > would be incorrect. Are we playing with definitions? > > All in all, I think what you're asking is for the debugger to be > informed of the situation in which it is invoked (e.g. because of > a signal, or because of an explicit call, when entering a function, when > exiting a function, ...) so that commands like `r' can tell whether > they'll be useful and so that we can provide a new command "continue > only if this was not a signal" that would behave somewhat like the old > "continue" (tho more cleanly since it would burp right away instead of > doing the previous dance of first continuing, then having the C-level > code figure out that you're trying to continue after a signal and hence > re-enter the debugger with a new error). Specifically, I'm saying that c should not unwind the stack after errors. Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 16:37 ` Helmut Eller @ 2011-09-09 21:44 ` Stefan Monnier 2011-09-10 18:27 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2011-09-09 21:44 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 > > There's nothing DWIMish at all about it. > That's in the eye beholder. Not at all: the code is proof that there is nothing DWIMish about it. I know DWIM when I see it, and I assure you there's no such thing here. > Let's assume we are hunting down some annoying bug. The debugger just > popped up and we execute the sequence: d c d c c c c. The last 4 c are > needed for a loop that has a call to debug. Now we are at a moderately > interesting place, lets continue: d c. The last c hits an error but we > are in a hurry and don't see it. Pressing c again suddenly brings us > back to top-level. Duh! The stack is gone. But the same happens in many other circumstances where no error shows up: the loop goes around N times, and you hit "c" just one extra time and poof the loop ends, returns to the caller who deletes the temp buffer and your network data is gone. I understand you liked the old behavior because it ended up providing a heuristic way to prevent you from stepping too far, and in your experience this worked well. >> All in all, I think what you're asking is for the debugger to be >> informed of the situation in which it is invoked (e.g. because of >> a signal, or because of an explicit call, when entering a function, when >> exiting a function, ...) so that commands like `r' can tell whether >> they'll be useful and so that we can provide a new command "continue >> only if this was not a signal" that would behave somewhat like the old >> "continue" (tho more cleanly since it would burp right away instead of >> doing the previous dance of first continuing, then having the C-level >> code figure out that you're trying to continue after a signal and hence >> re-enter the debugger with a new error). > Specifically, I'm saying that c should not unwind the stack after > errors. I understand that's what you want. The fixes I installed in the C side were done to make it possible for "c" to continue after an error, which is a very useful behavior in several cases. So I'm definitely not going to revert this change. What I can offer is to provide more flexibility so you could for instance rebind "c" to some command that simulates the behavior you used to get with "c". We could also consider changing "c" so it asks for confirmation before continuing from an error. But for any of that, we first have to change the code so that "c" can know whether we were called because of an error or not: currently "c" doesn't known that (and it didn't know that either in earlier Emacsen). Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 21:44 ` Stefan Monnier @ 2011-09-10 18:27 ` Helmut Eller 2011-09-19 21:17 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-10 18:27 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-09 21:44] writes: >> Specifically, I'm saying that c should not unwind the stack after >> errors. > > I understand that's what you want. The fixes I installed in the C side > were done to make it possible for "c" to continue after an error, which > is a very useful behavior in several cases. So I'm definitely not going > to revert this change. > > What I can offer is to provide more flexibility so you could for > instance rebind "c" to some command that simulates the behavior you used > to get with "c". We could also consider changing "c" so it asks for > confirmation before continuing from an error. > > But for any of that, we first have to change the code so that "c" can > know whether we were called because of an error or not: currently "c" > doesn't known that (and it didn't know that either in earlier Emacsen). The patch below is what I think that the debugger should do. Incidentally, C-M-c does pretty much the same as what c does currently. So, no new command to get the current behavior would be needed. === modified file 'lisp/emacs-lisp/debug.el' --- lisp/emacs-lisp/debug.el 2011-08-22 21:16:46 +0000 +++ lisp/emacs-lisp/debug.el 2011-09-10 18:23:13 +0000 @@ -98,6 +98,9 @@ (defvar inhibit-trace) ;Not yet implemented. +(defvar debugger-args nil + "Arguments passed to `debug'.") + ;;;###autoload (setq debugger 'debug) ;;;###autoload @@ -419,15 +422,27 @@ (message "Proceeding, will debug on next eval or call.") (exit-recursive-edit)) +(defun debugger-continuable-p () + "Can we reasonably continue from the current situation?" + (and debugger-may-continue + (not (eq (car debugger-args) + 'error)))) + (defun debugger-continue () "Continue, evaluating this expression without stopping." (interactive) - (unless debugger-may-continue - (error "Cannot continue")) - (message "Continuing.") + (cond ((debugger-condition-continuable-p) + (message "Continuing.") + (debugger-exit-recursive-edit)) + (t + (message "Cannot continue") + (ding)))) + +(defun debugger-exit-recursive-edit () + ;; Exit but first check if we've flagged some frame for + ;; debug-on-exit, in which case we'll probably come back to the + ;; debugger soon. (save-excursion - ;; Check to see if we've flagged some frame for debug-on-exit, in which - ;; case we'll probably come back to the debugger soon. (goto-char (point-min)) (if (re-search-forward "^\\* " nil t) (setq debugger-will-be-back t))) @@ -438,16 +453,14 @@ This is only useful when the value returned from the debugger will be used, such as in a debug on exit from a frame." (interactive "XReturn value (evaluated): ") - (setq debugger-value val) - (princ "Returning " t) - (prin1 debugger-value) - (save-excursion - ;; Check to see if we've flagged some frame for debug-on-exit, in which - ;; case we'll probably come back to the debugger soon. - (goto-char (point-min)) - (if (re-search-forward "^\\* " nil t) - (setq debugger-will-be-back t))) - (exit-recursive-edit)) + (cond ((debugger-condition-continuable-p) + (setq debugger-value val) + (princ "Returning " t) + (prin1 debugger-value) + (debugger-exit-recursive-edit)) + (t + (message "Cannot return") + (ding)))) (defun debugger-jump () "Continue to exit from this frame, with all debug-on-entry suspended." ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-10 18:27 ` Helmut Eller @ 2011-09-19 21:17 ` Stefan Monnier 2011-09-20 6:49 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2011-09-19 21:17 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 > Incidentally, C-M-c does pretty much the same as what c does currently. It does something similar but not identical and hence re-introduces some of the problems that the change you don't like aimed to solve. It's important to have a "c" that can "keep going (as much as possible) as if nothing happened". As you've shown, you can actually get your old behavior with something like (defadvice debugger-continue (before dont-continue-after-error activate) (if (eq (car debugger-args) 'error) (error "Can't continue from an error"))) > So, no new command to get the current behavior would be needed. Indeed. I've installed a change to catch the most common cases where debugger-return-value doesn't make sense. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-19 21:17 ` Stefan Monnier @ 2011-09-20 6:49 ` Helmut Eller 2011-09-20 21:53 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-20 6:49 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-19 21:17] writes: >> Incidentally, C-M-c does pretty much the same as what c does currently. > > It does something similar but not identical and hence re-introduces some > of the problems that the change you don't like aimed to solve. And what exactly is the difference between C-M-c and c? > It's important to have a "c" that can "keep going (as much as possible) > as if nothing happened". And why was this not important in previous releases? Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-20 6:49 ` Helmut Eller @ 2011-09-20 21:53 ` Stefan Monnier 2011-09-21 8:05 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2011-09-20 21:53 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 >>> Incidentally, C-M-c does pretty much the same as what c does currently. >> It does something similar but not identical and hence re-introduces some >> of the problems that the change you don't like aimed to solve. > And what exactly is the difference between C-M-c and c? C-M-c does a (throw 'exit), so in the case where we've caught a signal, it prevents the condition-case catchers from doing their job. >> It's important to have a "c" that can "keep going (as much as possible) >> as if nothing happened". > And why was this not important in previous releases? That's not a very constructive line of argument, I'm afraid. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-20 21:53 ` Stefan Monnier @ 2011-09-21 8:05 ` Helmut Eller 2011-09-21 19:09 ` Stefan Monnier 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-21 8:05 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-20 21:53] writes: >>>> Incidentally, C-M-c does pretty much the same as what c does currently. >>> It does something similar but not identical and hence re-introduces some >>> of the problems that the change you don't like aimed to solve. >> And what exactly is the difference between C-M-c and c? > > C-M-c does a (throw 'exit), so in the case where we've caught a signal, > it prevents the condition-case catchers from doing their job. As matter of fact, c calls exit-recursive-edit (= C-M-c). So (throw 'exit) can't be the difference. Also the debugger is usually not invoked if there is a matching condition handler, e.g. (let ((debug-on-error t)) (condition-case c (error "e") (error c))) doesn't invoke the debugger. Let's call this situation 0. We can have a matching condition handler (only) in these situations: 1. debug-on-error=t and the handler is flagged with debug, e.g.: (let ((debug-on-error t)) (condition-case c (error "e") ((debug error) c))) 2. debug-on-signal=t 3. debug-on-quit=t In 1, 2, and 3 it might be a good thing to continue to unwind the stack. But the situation I'm interested is like this: (let ((debug-on-error t)) (error "foo")) It is different from 0 and 1 and never has a matching condition handler. >>> It's important to have a "c" that can "keep going (as much as possible) >>> as if nothing happened". >> And why was this not important in previous releases? > > That's not a very constructive line of argument, I'm afraid. c now destroys information (backtrace, temporary buffers) in more situations than in previous releases. I hope that we agree on this. You claim that this is "important". You neither explain why it is important nor why not destroying information was a problem previously. Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-21 8:05 ` Helmut Eller @ 2011-09-21 19:09 ` Stefan Monnier 2011-09-21 19:53 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2011-09-21 19:09 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 >>>>> Incidentally, C-M-c does pretty much the same as what c does currently. >>>> It does something similar but not identical and hence re-introduces some >>>> of the problems that the change you don't like aimed to solve. >>> And what exactly is the difference between C-M-c and c? >> C-M-c does a (throw 'exit), so in the case where we've caught a signal, >> it prevents the condition-case catchers from doing their job. > As matter of fact, c calls exit-recursive-edit (= C-M-c). > So (throw 'exit) can't be the difference. Ah, yes, indeed, I forgot about that part. So yes, C-M-c behaves very similarly (other than details like keeping the window displayed if there's a upper-level frame marked for debug-on-exit). > c now destroys information (backtrace, temporary buffers) in more > situations than in previous releases. I hope that we agree on this. `c' always destroys information when it works. And since it now works in more cases, it indeed destroys information in more situations. I think it's a feature. > You claim that this is "important". You neither explain why it is > important nor why not destroying information was a problem previously. I already explained. You just disagree that this is important, and you instead think it's more important to use the "stop at error" as a heuristic to prevent you from stepping too far. My experience is different, so we disagree. Have you tried the defadvice I suggested? Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-21 19:09 ` Stefan Monnier @ 2011-09-21 19:53 ` Helmut Eller 2012-02-22 2:20 ` Glenn Morris 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-21 19:53 UTC (permalink / raw) To: 9463 * Stefan Monnier [2011-09-21 19:09] writes: >> You claim that this is "important". You neither explain why it is >> important nor why not destroying information was a problem previously. > > I already explained. You just disagree that this is important, and you > instead think it's more important to use the "stop at error" as > a heuristic to prevent you from stepping too far. My experience > is different, so we disagree. > Have you tried the defadvice I suggested? No, because I was hoping that reporting a bug is not a waste of time. Now I know better. Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-21 19:53 ` Helmut Eller @ 2012-02-22 2:20 ` Glenn Morris 0 siblings, 0 replies; 20+ messages in thread From: Glenn Morris @ 2012-02-22 2:20 UTC (permalink / raw) To: 9463-done Thanks for the report, but as was explained the behaviour is not going to change, so I am closing this as "wontfix". ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 2:23 ` Stefan Monnier 2011-09-09 6:53 ` Helmut Eller @ 2011-09-09 7:10 ` Eli Zaretskii 2011-09-09 7:36 ` Helmut Eller 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2011-09-09 7:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: eller.helmut, 9463 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Thu, 08 Sep 2011 22:23:09 -0400 > Cc: 9463@debbugs.gnu.org > > > I think the "do what would have happened if the debugger had not been > > called" thing should be a different command, like resignal or abort. > > Why? When the debugger is called in a non-error case, the "c" does just > that "do whatever would have happened if the debug call had no taken place". > > > c should only continue from truly continuable situations, like > > breakpoints. > > Again: why? I agree with Stefan. The current operation of `c' is consistent with what other debuggers do in this situation. For example, when GDB catches a fatal signal, typing `c' will simply let the program continue with the signal, which may mean it will crash. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 7:10 ` Eli Zaretskii @ 2011-09-09 7:36 ` Helmut Eller 2011-09-09 7:59 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: Helmut Eller @ 2011-09-09 7:36 UTC (permalink / raw) To: 9463 * Eli Zaretskii [2011-09-09 07:10] writes: >> From: Stefan Monnier <monnier@iro.umontreal.ca> >> Date: Thu, 08 Sep 2011 22:23:09 -0400 >> Cc: 9463@debbugs.gnu.org >> >> > I think the "do what would have happened if the debugger had not been >> > called" thing should be a different command, like resignal or abort. >> >> Why? When the debugger is called in a non-error case, the "c" does just >> that "do whatever would have happened if the debug call had no taken place". >> >> > c should only continue from truly continuable situations, like >> > breakpoints. >> >> Again: why? > > I agree with Stefan. The current operation of `c' is consistent with > what other debuggers do in this situation. For example, when GDB > catches a fatal signal, typing `c' will simply let the program > continue with the signal, which may mean it will crash. What's the point of being compatible with GDB but not with previous versions of the Elisp debugger or for that matter with other Lisp debuggers? For instance in Common Lisp (continue) invokes the current continue restart, but of course only if there is such a restart. If there is no continue restart (continue) doesn't unwind the stack and simply returns nil. (You'd have to know what a restart is to understand that paragraph, but the "what other languages/debuggers do" is a weak argument anyway.) Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 7:36 ` Helmut Eller @ 2011-09-09 7:59 ` Eli Zaretskii 2011-09-09 8:22 ` Helmut Eller 0 siblings, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2011-09-09 7:59 UTC (permalink / raw) To: Helmut Eller; +Cc: 9463 > From: Helmut Eller <eller.helmut@gmail.com> > Date: Fri, 09 Sep 2011 09:36:59 +0200 > > > I agree with Stefan. The current operation of `c' is consistent with > > what other debuggers do in this situation. For example, when GDB > > catches a fatal signal, typing `c' will simply let the program > > continue with the signal, which may mean it will crash. > > What's the point of being compatible with GDB but not with previous > versions of the Elisp debugger or for that matter with other Lisp > debuggers? At least some users expect the current behavior, I guess. (I don't use CL.) ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#9463: 24.0.50; Errors should not be continuable 2011-09-09 7:59 ` Eli Zaretskii @ 2011-09-09 8:22 ` Helmut Eller 0 siblings, 0 replies; 20+ messages in thread From: Helmut Eller @ 2011-09-09 8:22 UTC (permalink / raw) To: 9463 * Eli Zaretskii [2011-09-09 07:59] writes: >> From: Helmut Eller <eller.helmut@gmail.com> >> Date: Fri, 09 Sep 2011 09:36:59 +0200 >> >> > I agree with Stefan. The current operation of `c' is consistent with >> > what other debuggers do in this situation. For example, when GDB >> > catches a fatal signal, typing `c' will simply let the program >> > continue with the signal, which may mean it will crash. >> >> What's the point of being compatible with GDB but not with previous >> versions of the Elisp debugger or for that matter with other Lisp >> debuggers? > > At least some users expect the current behavior, I guess. Well, agreed. Ignorance is bliss. Helmut ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-02-22 2:20 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-08 12:01 bug#9463: 24.0.50; Errors should not be continuable Helmut Eller 2011-09-08 13:31 ` Stefan Monnier 2011-09-08 18:13 ` Helmut Eller 2011-09-09 2:23 ` Stefan Monnier 2011-09-09 6:53 ` Helmut Eller 2011-09-09 14:07 ` Stefan Monnier 2011-09-09 16:37 ` Helmut Eller 2011-09-09 21:44 ` Stefan Monnier 2011-09-10 18:27 ` Helmut Eller 2011-09-19 21:17 ` Stefan Monnier 2011-09-20 6:49 ` Helmut Eller 2011-09-20 21:53 ` Stefan Monnier 2011-09-21 8:05 ` Helmut Eller 2011-09-21 19:09 ` Stefan Monnier 2011-09-21 19:53 ` Helmut Eller 2012-02-22 2:20 ` Glenn Morris 2011-09-09 7:10 ` Eli Zaretskii 2011-09-09 7:36 ` Helmut Eller 2011-09-09 7:59 ` Eli Zaretskii 2011-09-09 8:22 ` Helmut Eller
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).