* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
@ 2016-10-04 16:30 Philipp Stephani
2016-10-04 17:15 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Philipp Stephani @ 2016-10-04 16:30 UTC (permalink / raw)
To: 24616
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 16:30 bug#24616: 26.0.50; No backtrace when emacsclient --eval fails Philipp Stephani
@ 2016-10-04 17:15 ` Eli Zaretskii
2016-10-04 20:52 ` Noam Postavsky
2016-10-24 0:51 ` Live System User
2 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2016-10-04 17:15 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 24616
> From: Philipp Stephani <p.stephani2@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 16:30 bug#24616: 26.0.50; No backtrace when emacsclient --eval fails Philipp Stephani
2016-10-04 17:15 ` Eli Zaretskii
@ 2016-10-04 20:52 ` Noam Postavsky
2016-10-04 22:28 ` Clément Pit--Claudel
2016-10-24 0:51 ` Live System User
2 siblings, 1 reply; 15+ messages in thread
From: Noam Postavsky @ 2016-10-04 20:52 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 24616
On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 20:52 ` Noam Postavsky
@ 2016-10-04 22:28 ` Clément Pit--Claudel
2016-10-04 23:50 ` Noam Postavsky
0 siblings, 1 reply; 15+ messages in thread
From: Clément Pit--Claudel @ 2016-10-04 22:28 UTC (permalink / raw)
To: 24616
[-- Attachment #1.1: Type: text/plain, Size: 697 bytes --]
On 2016-10-04 16:52, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 12:30 PM, Philipp Stephani <p.stephani2@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.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 22:28 ` Clément Pit--Claudel
@ 2016-10-04 23:50 ` Noam Postavsky
2016-10-05 0:02 ` Clément Pit--Claudel
2016-10-05 6:41 ` Eli Zaretskii
0 siblings, 2 replies; 15+ messages in thread
From: Noam Postavsky @ 2016-10-04 23:50 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: 24616
On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
<clement.pit@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@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 23:50 ` Noam Postavsky
@ 2016-10-05 0:02 ` Clément Pit--Claudel
2016-10-05 6:41 ` Eli Zaretskii
1 sibling, 0 replies; 15+ messages in thread
From: Clément Pit--Claudel @ 2016-10-05 0:02 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 24616
[-- Attachment #1.1: Type: text/plain, Size: 953 bytes --]
On 2016-10-04 19:50, Noam Postavsky wrote:
> On Tue, Oct 4, 2016 at 6:28 PM, Clément Pit--Claudel
> <clement.pit@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@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!
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 23:50 ` Noam Postavsky
2016-10-05 0:02 ` Clément Pit--Claudel
@ 2016-10-05 6:41 ` Eli Zaretskii
2016-10-22 15:35 ` npostavs
1 sibling, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2016-10-05 6:41 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 24616, clement.pit
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 4 Oct 2016 19:50:23 -0400
> Cc: 24616@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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-05 6:41 ` Eli Zaretskii
@ 2016-10-22 15:35 ` npostavs
2016-10-22 15:52 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: npostavs @ 2016-10-22 15:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24616, clement.pit
Eli Zaretskii <eliz@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
^ permalink raw reply related [flat|nested] 15+ messages in thread* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-22 15:35 ` npostavs
@ 2016-10-22 15:52 ` Eli Zaretskii
2016-10-22 16:08 ` npostavs
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2016-10-22 15:52 UTC (permalink / raw)
To: npostavs; +Cc: 24616, clement.pit
> From: npostavs@users.sourceforge.net
> Cc: 24616@debbugs.gnu.org, clement.pit@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.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-22 15:52 ` Eli Zaretskii
@ 2016-10-22 16:08 ` npostavs
2019-11-02 1:09 ` Stefan Kangas
0 siblings, 1 reply; 15+ messages in thread
From: npostavs @ 2016-10-22 16:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 24616, clement.pit
Eli Zaretskii <eliz@gnu.org> writes:
>> From: npostavs@users.sourceforge.net
>> Cc: 24616@debbugs.gnu.org, clement.pit@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".
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-22 16:08 ` npostavs
@ 2019-11-02 1:09 ` Stefan Kangas
2019-11-18 21:05 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Stefan Kangas @ 2019-11-02 1:09 UTC (permalink / raw)
To: npostavs; +Cc: 24616, clement.pit
npostavs@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2019-11-02 1:09 ` Stefan Kangas
@ 2019-11-18 21:05 ` Philipp Stephani
2019-11-19 14:31 ` Stefan Kangas
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2019-11-18 21:05 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 24616, Clément Pit--Claudel, Noam Postavsky
Am Sa., 2. Nov. 2019 um 02:10 Uhr schrieb Stefan Kangas <stefan@marxist.se>:
>
> npostavs@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2019-11-18 21:05 ` Philipp Stephani
@ 2019-11-19 14:31 ` Stefan Kangas
0 siblings, 0 replies; 15+ messages in thread
From: Stefan Kangas @ 2019-11-19 14:31 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 24616, Clément Pit--Claudel, Noam Postavsky
severity 24616 wishlist
thanks
Philipp Stephani <p.stephani2@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-04 16:30 bug#24616: 26.0.50; No backtrace when emacsclient --eval fails Philipp Stephani
2016-10-04 17:15 ` Eli Zaretskii
2016-10-04 20:52 ` Noam Postavsky
@ 2016-10-24 0:51 ` Live System User
2016-10-26 1:46 ` Noam Postavsky
2 siblings, 1 reply; 15+ messages in thread
From: Live System User @ 2016-10-24 0:51 UTC (permalink / raw)
To: npostavs; +Cc: 24616, clement.pit
npostavs@users.sourceforge.net writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: npostavs@users.sourceforge.net
>>> Cc: 24616@debbugs.gnu.org, clement.pit@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.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#24616: 26.0.50; No backtrace when emacsclient --eval fails
2016-10-24 0:51 ` Live System User
@ 2016-10-26 1:46 ` Noam Postavsky
0 siblings, 0 replies; 15+ messages in thread
From: Noam Postavsky @ 2016-10-26 1:46 UTC (permalink / raw)
To: Live System User; +Cc: 24616, Clément Pit--Claudel
On Sun, Oct 23, 2016 at 8:51 PM, Live System User <nyc4bos@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-11-19 14:31 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-04 16:30 bug#24616: 26.0.50; No backtrace when emacsclient --eval fails Philipp Stephani
2016-10-04 17:15 ` Eli Zaretskii
2016-10-04 20:52 ` Noam Postavsky
2016-10-04 22:28 ` Clément Pit--Claudel
2016-10-04 23:50 ` Noam Postavsky
2016-10-05 0:02 ` Clément Pit--Claudel
2016-10-05 6:41 ` Eli Zaretskii
2016-10-22 15:35 ` npostavs
2016-10-22 15:52 ` Eli Zaretskii
2016-10-22 16:08 ` npostavs
2019-11-02 1:09 ` Stefan Kangas
2019-11-18 21:05 ` Philipp Stephani
2019-11-19 14:31 ` Stefan Kangas
2016-10-24 0:51 ` Live System User
2016-10-26 1:46 ` Noam Postavsky
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).