Start the server. Then run e.g. $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' *ERROR*: foo Note that there's no backtrace. This makes it almost impossible to debug problems when using emacsclient. In GNU Emacs 26.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2016-10-04 built on unknown Repository revision: e2913dc880b9843bf69cf885270551bafeb46120 Windowing system distributor 'The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04 LTS Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules --enable-checking --enable-check-lisp-object-type' Configured features: XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-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 Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded 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 inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 97800 7962) (symbols 48 20400 0) (miscs 40 325 144) (strings 32 17966 4881) (string-bytes 1 589539) (vectors 16 13792) (vector-slots 8 454069 6477) (floats 8 183 13) (intervals 56 215 0) (buffers 976 12) (heap 1024 42234 1051)) -- Google Germany GmbH Erika-Mann-Straße 33 80636 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks. |
> From: Philipp Stephani <[hidden email]>
> Date: Tue, 04 Oct 2016 18:30:15 +0200 > > Start the server. > Then run e.g. > > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' > *ERROR*: foo > > Note that there's no backtrace. This makes it almost impossible to debug > problems when using emacsclient. See this discussion: http://lists.gnu.org/archive/html/emacs-devel/2016-08/msg00122.html |
In reply to this post by Philipp Stephani
On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <[hidden email]> wrote:
> > Start the server. > Then run e.g. > > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' > *ERROR*: foo > > Note that there's no backtrace. This makes it almost impossible to debug > problems when using emacsclient. > Just a note: you can get a backtrace by setting debug-on-signal instead of debug-on-error. |
On 2016-10-04 16:52, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <[hidden email]> wrote: >> >> Start the server. >> Then run e.g. >> >> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' >> *ERROR*: foo >> >> Note that there's no backtrace. This makes it almost impossible to debug >> problems when using emacsclient. >> > > Just a note: you can get a backtrace by setting debug-on-signal > instead of debug-on-error. $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' *ERROR*: foo Am I missing something obvious? Cheers, Clément. |
On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
<[hidden email]> wrote: > On 2016-10-04 16:52, Noam Postavsky wrote: >> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <[hidden email]> wrote: >>> >>> Start the server. >>> Then run e.g. >>> >>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' >>> *ERROR*: foo >>> >>> Note that there's no backtrace. This makes it almost impossible to debug >>> problems when using emacsclient. >>> >> >> Just a note: you can get a backtrace by setting debug-on-signal >> instead of debug-on-error. > > Really? > > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' > *ERROR*: foo > > Am I missing something obvious? The backtrace shows up in Emacs, where the server is running. |
On 2016-10-04 19:50, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel > <[hidden email]> wrote: >> On 2016-10-04 16:52, Noam Postavsky wrote: >>> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <[hidden email]> wrote: >>>> >>>> Start the server. >>>> Then run e.g. >>>> >>>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' >>>> *ERROR*: foo >>>> >>>> Note that there's no backtrace. This makes it almost impossible to debug >>>> problems when using emacsclient. >>>> >>> >>> Just a note: you can get a backtrace by setting debug-on-signal >>> instead of debug-on-error. >> >> Really? >> >> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' >> *ERROR*: foo >> >> Am I missing something obvious? > > The backtrace shows up in Emacs, where the server is running. |
In reply to this post by Noam Postavsky-2
> From: Noam Postavsky <[hidden email]>
> Date: Tue, 4 Oct 2016 19:50:23 -0400 > Cc: [hidden email] > > >>> $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-error t) (f))' > >>> *ERROR*: foo > >>> > >>> Note that there's no backtrace. This makes it almost impossible to debug > >>> problems when using emacsclient. > >>> > >> > >> Just a note: you can get a backtrace by setting debug-on-signal > >> instead of debug-on-error. > > > > Really? > > > > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' > > *ERROR*: foo > > > > Am I missing something obvious? > > The backtrace shows up in Emacs, where the server is running. How about adding this to debugging.texi? |
Eli Zaretskii <[hidden email]> writes:
>> >> Just a note: you can get a backtrace by setting debug-on-signal >> >> instead of debug-on-error. >> > >> > Really? >> > >> > $ emacsclient --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' >> > *ERROR*: foo >> > >> > Am I missing something obvious? >> >> The backtrace shows up in Emacs, where the server is running. > > How about adding this to debugging.texi? Something like this? diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi index c88a2fa..bb3ced4 100644 --- i/doc/lispref/debugging.texi +++ w/doc/lispref/debugging.texi @@ -152,6 +152,11 @@ Error Debugging must still fulfill the criteria specified by @code{debug-on-error} and @code{debug-ignored-errors}.) +For example, setting this variable is useful to get a backtrace from +code evaluated by emacsclient. If elisp code evaluated by emacsclient +signals an error while this variable is non-@code{nil}, the backtrace +will popup in the running Emacs. + @strong{Warning:} Setting this variable to non-@code{nil} may have annoying effects. Various parts of Emacs catch errors in the normal course of affairs, and you may not even realize that errors happen |
> From: [hidden email]
> Cc: [hidden email], [hidden email] > Date: Sat, 22 Oct 2016 11:35:49 -0400 > > Something like this? > > diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi > index c88a2fa..bb3ced4 100644 > --- i/doc/lispref/debugging.texi > +++ w/doc/lispref/debugging.texi > @@ -152,6 +152,11 @@ Error Debugging > must still fulfill the criteria specified by @code{debug-on-error} and > @code{debug-ignored-errors}.) > > +For example, setting this variable is useful to get a backtrace from > +code evaluated by emacsclient. If elisp code evaluated by emacsclient > +signals an error while this variable is non-@code{nil}, the backtrace > +will popup in the running Emacs. > + Yes, but please mention "--eval", and add an index entry so that this text would be easier to locate. Something like this: @cindex emacsclient, getting a backtrace @cindex backtrace from emacsclient's @option{--eval} Also, a nit: I don't think we use "elisp" in the manual, we say "Lisp" instead. Thanks. |
Eli Zaretskii <[hidden email]> writes:
>> From: [hidden email] >> Cc: [hidden email], [hidden email] >> Date: Sat, 22 Oct 2016 11:35:49 -0400 >> >> Something like this? >> >> diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi >> index c88a2fa..bb3ced4 100644 >> --- i/doc/lispref/debugging.texi >> +++ w/doc/lispref/debugging.texi >> @@ -152,6 +152,11 @@ Error Debugging >> must still fulfill the criteria specified by @code{debug-on-error} and >> @code{debug-ignored-errors}.) >> >> +For example, setting this variable is useful to get a backtrace from >> +code evaluated by emacsclient. If elisp code evaluated by emacsclient >> +signals an error while this variable is non-@code{nil}, the backtrace >> +will popup in the running Emacs. >> + > > Yes, but please mention "--eval", and add an index entry so that this > text would be easier to locate. Something like this: > > @cindex emacsclient, getting a backtrace > @cindex backtrace from emacsclient's @option{--eval} > > Also, a nit: I don't think we use "elisp" in the manual, we say > "Lisp" instead. > > Thanks. Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp errors". |
In reply to this post by Philipp Stephani
[hidden email] writes: > Eli Zaretskii <[hidden email]> writes: > >>> From: [hidden email] >>> Cc: [hidden email], [hidden email] >>> Date: Sat, 22 Oct 2016 11:35:49 -0400 >>> >>> Something like this? >>> >>> diff --git i/doc/lispref/debugging.texi w/doc/lispref/debugging.texi >>> index c88a2fa..bb3ced4 100644 >>> --- i/doc/lispref/debugging.texi >>> +++ w/doc/lispref/debugging.texi >>> @@ -152,6 +152,11 @@ Error Debugging >>> must still fulfill the criteria specified by @code{debug-on-error} and >>> @code{debug-ignored-errors}.) >>> >>> +For example, setting this variable is useful to get a backtrace from >>> +code evaluated by emacsclient. If elisp code evaluated by emacsclient >>> +signals an error while this variable is non-@code{nil}, the backtrace >>> +will popup in the running Emacs. >>> + >> >> Yes, but please mention "--eval", and add an index entry so that this >> text would be easier to locate. Something like this: >> >> @cindex emacsclient, getting a backtrace >> @cindex backtrace from emacsclient's @option{--eval} >> >> Also, a nit: I don't think we use "elisp" in the manual, we say >> "Lisp" instead. >> >> Thanks. > > Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp > errors". This example doesn't work for me with Emacs daemon and the default Emacs terminal: 0. emacs -Q --daemon Warning: due to a long standing Gtk+ bug http://bugzilla.gnome.org/show_bug.cgi?id=85715 Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost. Using an Emacs configured with --with-x-toolkit=lucid does not have this problem. Starting Emacs daemon. 1. emacsclient -n --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' (Aside: Although the option "-n" was used, Emacs doesn't return to the command prompt.) 2. From another xterm, connect to the Emacs server in order to see the *backtrace* buffer that should have been created: emacsclient -n non-existant-file.txt You now see an Emacs in the default TTY-mode with the *backtrace* buffer displayed: Debugger entered--Lisp error: (error "foo") signal(error ("foo")) error("foo") f() (progn (defun f nil (error "foo")) (setq debug-on-signal t debug-on-error t) $ eval((progn (defun f nil (error "foo")) (setq debug-on-signal t debug-on-erro$ server-eval-and-print("(progn (defun f () (error \"foo\")) (setq debug-on-sig$ #[0 "\302\301\242\300\"\207" [#<process server <1>> ("(progn (defun f () (err$ funcall(#[0 "\302\301\242\300\"\207" [#<process server <1>> ("(progn (defun f$ mapc(funcall (#[0 "\302\301\242\300\"\207" [#<process server <1>> ("(progn (d$ server-execute(#<process server <1>> nil t (#[0 "\302\301\242\300\"\207" [#<p$ #[0 "r\310^N^K!q\210\305\242\203^X^@\311\305\242!\203^X^@\305\242\202^Z^@^N\f$ server-execute-continuation(#<process server <1>>) server-process-filter(#<process server <1>> "-dir /home/liveuser/ -nowait -cu$ However, when you press any keycords, like "C-x C-b" (list-buffers), nothing happens! You can't "C-x k" (kill-buffer) or "M-x" (execute-extended-command). The only thing you can do is kill Emacs from another terminal shell prompt. You can, of course, do all f these things if you use Emacs in GUI-mode (emacsclient -c ...) instead of its default TTY-mode. Thanks. |
On Sun, Oct 23, 2016 at 8:51 PM, Live System User <[hidden email]> wrote:
> > This example doesn't work for me with Emacs daemon and the default > Emacs terminal: > > 0. emacs -Q --daemon > Warning: due to a long standing Gtk+ bug > http://bugzilla.gnome.org/show_bug.cgi?id=85715 > Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost. > Using an Emacs configured with --with-x-toolkit=lucid does not have this problem. > Starting Emacs daemon. > > 1. emacsclient -n --eval '(progn (defun f () (error "foo")) (setq debug-on-signal t debug-on-error t) (f))' > > (Aside: Although the option "-n" was used, Emacs doesn't return to the > command prompt.) > > > 2. From another xterm, connect to the Emacs server in order to see the > *backtrace* buffer that should have been created: > > emacsclient -n non-existant-file.txt > > You now see an Emacs in the default TTY-mode with the *backtrace* buffer > displayed: Hmm, I just get an empty *backtrace* buffer in that case. If I start a tty-mode client before making the error, the backtrace pops up as expected with no problems though. |
In reply to this post by Noam Postavsky-2
[hidden email] writes:
> Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp > errors". Is there anything more to do here, or can this bug report be closed? If I don't hear back within a couple of weeks, I'll just go ahead and close this bug. Best regards, Stefan Kangas |
Am Sa., 2. Nov. 2019 um 02:10 Uhr schrieb Stefan Kangas <[hidden email]>:
> > [hidden email] writes: > > > Fixed and pushed as b2ba6307 "Explain how to debug emacsclient lisp > > errors". > > Is there anything more to do here, or can this bug report be closed? Well, ideally the stacktrace would be printed on the terminal invoking emacsclient to ease debugging. |
severity 24616 wishlist
thanks Philipp Stephani <[hidden email]> writes: > > Is there anything more to do here, or can this bug report be closed? > > Well, ideally the stacktrace would be printed on the terminal invoking > emacsclient to ease debugging. OK. You're probably right in that it would make for a better user experience in this case. I'm not sure how easy or hard this would be to do, but as it stands I think this is a feature request rather than a bug. I'm therefore changing the severity to wishlist. Feel free to change the severity back to "minor" if you disagree. Best regards, Stefan Kangas |
Free forum by Nabble | Edit this page |