Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: The complication seems very minor as I see it. Sure. That's why real examples will easily win the day. Yes, the important thing is of course that there is a way to make it easy to debug then. If such cases shows up my little patch can be used. Maybe the hardest thing is to convince me I am not easy to convince ... ;-) Hummm... I've thought past threads were a convincing example ;-) I hope for the best, we will see. Life is a long learning experience. :-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Juanma Barranquero <[EMAIL PROTECTED]> wrote: Hummm... I've thought past threads were a convincing example ;-) s/'ve/ would've/ Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: The complication seems very minor as I see it. Sure. That's why real examples will easily win the day. Maybe the hardest thing is to convince me I am not easy to convince ... ;-) Hummm... I've thought past threads were a convincing example ;-) I looked at the problem just because Klaus Z was doing something in the background from emacsclient. I know. I was following the other thread too. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? I'm not sure. On one hand, if there's no trouble, there's no need to complicate things. On the other, yeah, the context is slightly The complication seems very minor as I see it. I am glad to read that ;-) Eh, so long as you're also ready to be easily convinced... Maybe the hardest thing is to convince me I am not easy to convince ... ;-) That depends of what you're doing with "emacsclient -n --eval". I'd expect the user (or client program) to detect that nothing is happening :) I looked at the problem just because Klaus Z was doing something in the background from emacsclient. Perhaps. All this is in the purely hypothetical realm right now. Yes, probably. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? I'm not sure. On one hand, if there's no trouble, there's no need to complicate things. On the other, yeah, the context is slightly different, but do you really expect to have to debug much Emacs library code which fails in the context of emacsclient --eval? (I say "Emacs library code" because if the trouble is in the evaled string, the stderr message is already a good clue.) I am glad to read that ;-) Eh, so long as you're also ready to be easily convinced... Then could it not easily happen that the source of the problem is not detected? That depends of what you're doing with "emacsclient -n --eval". I'd expect the user (or client program) to detect that nothing is happening :) Is not that an argument for beeing able to get a traceback the way I suggested? Perhaps. All this is in the purely hypothetical realm right now. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: Perhaps you're right, but I'd like to see some examples of things that are much easier to debug from --eval than directly. I have no examples at hand, but the context where the functions are running is slightly different when they are called from emacsclient. Is not that enough? It might not be the right thing to do in all cases. No. But if it is normal operation for your emacsclient invocation to fail sometimes, it'd be sensible to *not* use -n and read emacsclient's stderr output and exit code; and if it is not normal, the moment you detect a problem you can remove the -n and try again. Sure, but see above. This is not to say that I oppose the feature; I just don't feel it compelling right now (but I can be easily convinced :) I am glad to read that ;-) BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? Not currently, no. It returns an error for any trouble communicating with Emacs, not because of what happens to the info exchanged between them. Then could it not easily happen that the source of the problem is not detected? Is not that an argument for beeing able to get a traceback the way I suggested? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Some errors are very hard to track down. I think it can help very much to be able to directly debug what happens when the call is from emacsclient. Perhaps you're right, but I'd like to see some examples of things that are much easier to debug from --eval than directly. It might not be the right thing to do in all cases. No. But if it is normal operation for your emacsclient invocation to fail sometimes, it'd be sensible to *not* use -n and read emacsclient's stderr output and exit code; and if it is not normal, the moment you detect a problem you can remove the -n and try again. This is not to say that I oppose the feature; I just don't feel it compelling right now (but I can be easily convinced :) BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? Not currently, no. It returns an error for any trouble communicating with Emacs, not because of what happens to the info exchanged between them. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: - It is not necessarily "emacsclient -e BIG-COMMAND-LINE-MISTAKE", it could equally well be somewhere in the elisp libraries. Fair enough, though if you set debug-on-error to debug the problem, it will happen also if you evaluate the code from inside Emacs (as opposed to "from emacsclient"). Some errors are very hard to track down. I think it can help very much to be able to directly debug what happens when the call is from emacsclient. - If you use "-n" you will see nothing as it is now. That's no reason, I think. If you're worried about errors, don't use -n. It might not be the right thing to do in all cases. BTW, does emacsclient exit with an error when there is an error evaluating the code that is sent from emacsclient? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: - It is not necessarily "emacsclient -e BIG-COMMAND-LINE-MISTAKE", it could equally well be somewhere in the elisp libraries. Fair enough, though if you set debug-on-error to debug the problem, it will happen also if you evaluate the code from inside Emacs (as opposed to "from emacsclient"). - If you use "-n" you will see nothing as it is now. That's no reason, I think. If you're worried about errors, don't use -n. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Why would "emacsclient --eval BIG-MISTAKE" cause a traceback on Emacs, even if debug-on-error is t? It already shows an error on the output of emacsclient. Two reasons: - It is not necessarily "emacsclient -e BIG-COMMAND-LINE-MISTAKE", it could equally well be somewhere in the elisp libraries. - If you use "-n" you will see nothing as it is now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Why would "emacsclient --eval BIG-MISTAKE" cause a traceback on Emacs, even if debug-on-error is t? It already shows an error on the output of emacsclient. It is not much, just two or three new lines actually. Aha. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Would it not be easier if you get a normal backtrace if debug-on-error is t? Perhaps. OTOH, it is an error in an emacsclient-sent string to evaluate an Error *in* Emacs? Eh, you lost me on this one ;-) -- I do not understand the context. Can you please explain? Something like this can be used in server.el, server-process-filter: Can you please send it as a patch? Otherwise it's kind of difficult to see what's changing. It is not much, just two or three new lines actually. (The line numbers below are not correct.) *** c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff972RQU 2007-05-16 13:55:37.203125000 +0200 --- c:/emacs/p/070515/emacs/lisp/server.el 2007-05-16 13:32:13.328125000 +0200 *** *** 469,477 (setq arg (decode-coding-string arg coding-system))) (if eval (let* (errorp ! (v (condition-case errobj (eval (car (read-from-string arg))) ! (error (setq errorp t) errobj (when v (with-temp-buffer (let ((standard-output (current-buffer))) --- 482,493 (setq arg (decode-coding-string arg coding-system))) (if eval (let* (errorp ! (v ! (if debug-on-error ! (eval (car (read-from-string arg))) !(condition-case errobj (eval (car (read-from-string arg))) ! (error (setq errorp t) errobj) (when v (with-temp-buffer (let ((standard-output (current-buffer))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Would it not be easier if you get a normal backtrace if debug-on-error is t? Perhaps. OTOH, it is an error in an emacsclient-sent string to evaluate an Error *in* Emacs? Something like this can be used in server.el, server-process-filter: Can you please send it as a patch? Otherwise it's kind of difficult to see what's changing. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Sorry, I was using -n too, forgot that. With -n you do not see the error anywhere. That's what I would expect. You're saying to emacsclient to no expect any answer, after all. You can always do: emacsclient -n -e "(condition-case nil (my-bad-fun) (error (raise-frame) (backtrace)))" or something like that if you want to see errors in the server. Would it not be easier if you get a normal backtrace if debug-on-error is t? Something like this can be used in server.el, server-process-filter: (if eval (let* (errorp (v (if debug-on-error (eval (car (read-from-string arg))) (condition-case errobj (eval (car (read-from-string arg))) (error (setq errorp t) errobj) (when v (with-temp-buffer (let ((standard-output (current-buffer))) (when errorp (princ "error: ")) (pp v) (ignore-errors (process-send-region proc (point-min) (point-max))) I have just added the (if debug-on-error ...) here. Maybe there should be another, server specific variable too so that one can have debug-on-error t without getting a backtrace for this case. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/16/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: Sorry, I was using -n too, forgot that. With -n you do not see the error anywhere. That's what I would expect. You're saying to emacsclient to no expect any answer, after all. You can always do: emacsclient -n -e "(condition-case nil (my-bad-fun) (error (raise-frame) (backtrace)))" or something like that if you want to see errors in the server. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
Juanma Barranquero wrote: On 5/15/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: If I do something like emacsclient -e (my-bad-fun) where my-bad-fun is not defined or contains an error I see no backtrace even if debug-on-error is t. In fact I see nothing. C:\> emacsclient -e (my-bad-fun) error: (void-function my-bad-fun) Sorry, I was using -n too, forgot that. With -n you do not see the error anywhere. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Debug on error and Emacs client
On 5/15/07, Lennart Borgman (gmail) <[EMAIL PROTECTED]> wrote: If I do something like emacsclient -e (my-bad-fun) where my-bad-fun is not defined or contains an error I see no backtrace even if debug-on-error is t. In fact I see nothing. C:\> emacsclient -e (my-bad-fun) error: (void-function my-bad-fun) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Debug on error and Emacs client
It seems like errors are not handled as I expect them too when using Emacs client. If I do something like emacsclient -e (my-bad-fun) where my-bad-fun is not defined or contains an error I see no backtrace even if debug-on-error is t. In fact I see nothing. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-05-06 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug