If you are using the XEmacs editor then you should probably set up gnuserv. That will allow you to have the core interpreter running in background so each subsequent “start” will be fast. Instead of starting a new instance, you will of course only open a new frame (window) using the gnuclient tool.

Whenever you want to “exit” the editor then, you should instead just close the frame (C-x 5 0) or mark the file as done by clicking on [Done] in the menu bar or using C-x #

As usual, if you want to open the frame in a terminal, use gnuclient -nw

One way to achieve this is to make the background task start on login and have it respawn whenever you really exit the editor. This makes it convenient if you really need to cycle the environment at some time.

I’m using the following small script to do this, let’s call it gnuserv-xemacs-unmapped-loop:

#!/bin/zsh

ping=(gnuclient -batch -eval t)

if { $ping >/dev/null 2>&1 } { exit }

xemacs==gnuclient
xemacs=${xemacs:h}/xemacs

{ $xemacs -unmapped -f gnuserv-start 2>&2 2>&1 1>&3 | grep 'Gui error: X server not responding' && exit } 3>&1

exec $0

This will assume that xemacs is in the same place where gnuclient is. The grep makes sure that we don’t get into an endless loop when the X server goes away. Next, put this file in your autostart folder by creating a .desktop file in ~/.config/autostart:

[Desktop Entry]
Name=XEmacs Gnuserv
Terminal=false
Type=Application
NoDisplay=true
Exec=gnuserv-xemacs-unmapped-loop

Now it will automatically start the gnuserv on your Gnome startup.

Finally, you will want to start using “gnuclient” instead of xemacs to open new frames connected with this instance. Instead of that, I opted to write a replacement xemacs command:

#!/bin/zsh

ping=(gnuclient -batch -eval t)

ctr=100

until { $ping >/dev/null 2>&1 } {
	if [[ ! $ctr -gt 0 ]] {
		break
	}
	sleep 0.1
	((--ctr))
}

exec gnuclient $@

This will check a 100 times if gnuserv is up and running, and connect to it. Because whenever you just log in or just quit XEmacs (using C-x C-c), it will take a little while for the gnuserv to be ready. So instead of being presented with a “connection refused”-like message, we are just waiting a bit for it.

If you’re using SSH forwarding and want to connect to your XEmacs, you might need to modify the xauth database. openssh apparently creates an Xauthority different from the gdm one, so when trying to run gnuclient you will see “X11 connection rejected because of wrong authentication”. On login, you might see a nice message such as “/usr/bin/xauth: creating new authority file” reminding you of such troubles.

One possible fix is to import this file into the gnuserv xauth database with a command such as

xauth list | while { read tok } { gnuclient -batch -f "shell-command \"xauth add $tok\"" }

on the remote host. You can get rid of it by replacing add with remove, naturally.

See also:
dtemacs - Emacs/gnuserv start script
XEmacs/gnuserv start script
XEmacs FAQ - running gnuserv
XEmacs bug tracker - xauth problem
Mailing list entry about XEmacs & xauth

gnuplot is a great program for creating graphs.

Sometimes you’d like to use it remote or even locally without the need to spawn an X11, Wx, Qt or PostScript viewer. Especially when working remotely without X forwarding, wouldn’t it be nice to use Xterms Tektronix support to do the drawing?

As it has, gnuplot does do some tek, but it works rather awkward horribly with Xterm, as it only switches to tek mode once and never back to text mode! Some people even suggest adding Xterm keyboard bindings to cope with this misdesign. Unbearable! How about simply fixing the tek entry to send the correct codes to Xterm?

That’s what I did, if you want it just get the appropriate patch from their sourceforge tracker, either one that adds xterm support to gnuplot for the current cvs as of today or one that patches on xterm tek support on gnuplot 4.2.5