Ar an triú lá de mí Meitheamh, scríobh Hauke Fath: XEmacs with gnuserv currently needs at least one frame. It’s not possible to start up an XEmacs with, only, a gnuserv process waiting for input. My approach is to start a TTY XEmacs using screen(1), and attach to it using gnuclient as needed. This is not hugely different from attaching to it using screen(1), but does have the advantage that you can attach X11 gnuclient instances to the TTY XEmacs, and that screen(1) doesn’t eat up C-a keystrokes :) . (Something easily worked around, I know, but an annoyance all the same.) Relevant command: screen -d -m xemacs If started on a machine with X11 support, you may need to unset DISPLAY in a shell function to have this work. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after forty pints of stout’ (C. Moore)

On 2019-06-03 15:48, Hauke Fath wrote: Since I mentioned this... My script will try to attach to a running gnuserv, and start a new one if that fails: if ! gnuclient -batch -eval t >/dev/null 2>&1 then xemacs -unmapped -eval gnuserv-start & sleep 1 until gnuclient -batch -eval t >/dev/null 2>&1 do sleep 1 done fi This works as intended, most of the time. But every now and then, the gnuserve instance so created will not be responsive, and the until keeps looping. Every new invocation of the script will leave behind another xemacs process running an unresponsive gnuserv. Funny enough, starting % xemacs -unmapped -eval gnuserv-start & in another xterm will result in an accessible gnuserv... Usually this problem appears and disappears in the context of seemingly unrelated system updates and/or xemacs rebuilds. Can anybody make heads or tails of the above, or provide debugging tips? Cheerio, hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344