GNU bug report logs - #24616
26.0.50; No backtrace when emacsclient --eval fails

Previous Next

To reply to this bug, email your comments to 24616 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50; No backtrace when emacsclient --eval fails
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.


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.

Message #8 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24616 <at> debbugs.gnu.org
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 04 Oct 2016 20:15:51 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> 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

Message #11 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24616 <at> debbugs.gnu.org
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 4 Oct 2016 16:52:29 -0400

On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2 <at> gmail.com> 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.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 4 Oct 2016 18:28:07 -0400

[Message part 1 (text/plain, inline)]

On 2016-10-04 16:52, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2 <at> gmail.com> 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?

Cheers,
Clément.

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Clément Pit--Claudel <clement.pit <at> gmail.com>
Cc: 24616 <at> debbugs.gnu.org
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 4 Oct 2016 19:50:23 -0400

On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
<clement.pit <at> gmail.com> wrote:
> On 2016-10-04 16:52, Noam Postavsky wrote:
>> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2 <at> gmail.com> 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.

Message #20 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit--Claudel <clement.pit <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 24616 <at> debbugs.gnu.org
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 4 Oct 2016 20:02:54 -0400

[Message part 1 (text/plain, inline)]

On 2016-10-04 19:50, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
> <clement.pit <at> gmail.com> wrote:
>> On 2016-10-04 16:52, Noam Postavsky wrote:
>>> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2 <at> gmail.com> 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.

Thanks for clarifying!

[signature.asc (application/pgp-signature, attachment)]

Message #23 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 24616 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Wed, 05 Oct 2016 09:41:08 +0300

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Tue, 4 Oct 2016 19:50:23 -0400
> Cc: 24616 <at> debbugs.gnu.org
> 
> >>> $ 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?

Message #26 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24616 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Sat, 22 Oct 2016 11:35:49 -0400

Eli Zaretskii <eliz <at> gnu.org> 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

Message #29 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 24616 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Sat, 22 Oct 2016 18:52:54 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 24616 <at> debbugs.gnu.org,  clement.pit <at> gmail.com
> 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.

Message #32 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24616 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Sat, 22 Oct 2016 12:08:47 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: npostavs <at> users.sourceforge.net
>> Cc: 24616 <at> debbugs.gnu.org,  clement.pit <at> gmail.com
>> 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".

Message #35 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Live System User <nyc4bos <at> aol.com>
To: npostavs <at> users.sourceforge.net
Cc: 24616 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, clement.pit <at> gmail.com
Subject: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Sun, 23 Oct 2016 20:51:19 -0400

npostavs <at> users.sourceforge.net writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: npostavs <at> users.sourceforge.net
>>> Cc: 24616 <at> debbugs.gnu.org,  clement.pit <at> gmail.com
>>> 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.

Message #38 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Live System User <nyc4bos <at> aol.com>
Cc: 24616 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Clément Pit--Claudel <clement.pit <at> gmail.com>
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 25 Oct 2016 21:46:40 -0400

On Sun, Oct 23, 2016 at 8:51 PM, Live System User <nyc4bos <at> aol.com> 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.

Message #41 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: npostavs <at> users.sourceforge.net
Cc: Eli Zaretskii <eliz <at> gnu.org>, 24616 <at> debbugs.gnu.org, clement.pit <at> gmail.com
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Sat, 02 Nov 2019 02:09:16 +0100

npostavs <at> users.sourceforge.net 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

Message #44 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 24616 <at> debbugs.gnu.org,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Mon, 18 Nov 2019 22:05:15 +0100

Am Sa., 2. Nov. 2019 um 02:10 Uhr schrieb Stefan Kangas <stefan <at> marxist.se>:
>
> npostavs <at> users.sourceforge.net 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.

Message #47 received at 24616 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 24616 <at> debbugs.gnu.org,
 Clément Pit--Claudel <clement.pit <at> gmail.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
Date: Tue, 19 Nov 2019 15:31:15 +0100

severity 24616 wishlist
thanks

Philipp Stephani <p.stephani2 <at> gmail.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.