Re: Bug report from debian user about gnuclient
On Tue, 22 Apr 2003, James LewisMoss wrote:
>>>>> "Dres" == James LewisMoss
<dres(a)lewismoss.org> writes:
>>> No core file is left.
Stephen> Well, get him to switch them on. ulimit -c unlimited.
Stephen> Although it probably won't help all that much since I
Stephen> suppose the binary is stripped....
already done.
>>> It'd certainly be great if frames starting by the
lisp function
>>> (gnuserv-edit-files) ignored any X-errors, so the underlying
>>> xemacs process doesn't die.
Stephen> Not really. That would probably result in "Energizer Bunny"
Stephen> syndrome (XEmacs consuming 100% of CPU in a tight loop
Stephen> looking for X input).
Stephen> Exactly what is being done here? Are there multiple
Stephen> displays involved, or are all the gnuclients being run from
Stephen> the same display? If there are multiple displays, then
Stephen> XEmacs shouldn't die, I think.
Yep - the gnuserv process is run on server hexane.
From "client1" I run
gnuclient -h hexane -display `hostname -f`$DISPLAY "$＠" &
and client2 runs the same (I was surprised I needed to supply the
-display, but then again, looking at this elisp gnuclient passes, it is
not surprising gnuserv wouldn't know where to actually start the display
frame).
Stephen> If there's only one display, then the thing to do is
not use
Stephen> -unmapped. I agree it would be cool if we could arrange for
Stephen> XEmacs to not die in this circumstance, but this is a hard
Stephen> problem, because most users _do_ want XEmacs to die (since
Stephen> they shut down XEmacs by killing the X server process or
Stephen> logging out from XDM).
Indeed. But if it can be coded, it's just a simple matter of
customisations:)
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
"I give up," said Pierre de Fermat's friend. "How DO you keep a
mathematician busy for 350 years?"