Re: automatic selection of emacsclient/emacs?

[Floyd L. Davidson]

Dan Elliott <dan-underscore-elliott-at-cox-dot-net@spamispathetic.org> wrote:
>Hattuari wrote:
>> Is there a clean way to get Emacs to start as a client when there is an
>> available server?  I find it moderately annoying to have to look around to
>> see if there is already an instance of Emacs started in order to determine
>> if I should enter `emacs' or `emacsclient'. I much prefer running
>> emacsclient when I already have one instance of Emacs running.

I've seen code to do that somewhere...  but I didn't find it
particularly useful (though you might) for reasons I'll describe
below.

>> One option
>> is to try and sniff for emacs with ps and filter out the current processes
>> such as grep emacs, and (assuming the script I'm running is also called
>> emacs) the launch script.  It would seem more correct to directly check to
>> see if the service is available.  Is there such a capability?
>
>Will I get flammed if I ask what the benefit of running emacs as
>a client (opposed to the "usual" way) would be?  Could this be
>an alternative to using TRAMP?

The number one benefit historically was speed of invocation.
Imagine what it was like back when 10 MHz 68010 cpu's were
commonly what an "Engineering Workstation" was using!  Nobody
wants to wait 1-2 minutes for the editor to load...

Today of course we all have supercomputers, and Emacs loads fast
enough that some people even think it is "fast".  The client is
*faster*!!

Beyond that, if the server is always running, there are a few
more (dis)advantages. The client's frame can be dumped while it
still has active files buffered, and they will be persistent.
Odd things like search strings and the delete buffer are kept by
the server instead of the client, and are therefore also
persistent.  Which makes it possible to fire up another instance
of the client, and use exactly the same (presumably complex and
difficult to type in) search pattern that was last being used by
a client process.

Or...  yank back the text just deleted and then discovered to
still be need!  Or yank it back into a totally different file.
And of course the whole delete buffer ring is still there...

Alas, some of that can get in the way too.  For example, I run a
separate instance of XEmacs/gnus for news and mail, because
there are often literally dozens of buffers active on that
instance and they absolutely get in the way of normal editing.
Custom keymaps can also be troublesum.

So, for me the solution is to run a single (X)Emacs server
instance, and _leave_ _it_ _running_ _all_ _the_ _time_.  I start my
server automatically when the window manager is invoked, with a
command that looks like this:

 /usr/local/bin/xemacs -l ~/.semacs -iconic -g 100x30 -T "XEmacs Server" &

(The ~/.semacs file is magic, and I'll explain that down a bit.)

There are also several aliases defined in ~/.bashrc, to make life
easier:

To start up a server process:

 alias startxemacs='/usr/local/bin/xemacs -l ~/.semacs -iconic \
                    -g 100x30 -T "XEmacs Server" &'

To start up xemacs for news and email:

 alias        gnus='/usr/local/bin/xemacs -l ~/.gemacs -f gnus \
                   -g 105x35+30+-36  -T "GNUS" 2>/dev/null &'

My normal "editor" command is this one:

 alias          em='/usr/local/bin/gnuclient'

And for use from a virtual console:

 alias          pw='/usr/local/bin/xemacs -nw'

Note the -l options, which load extra init files.  The ~./gemacs
file sets up paths and so on for running gnus, and the "gnus"
alias invokes gnus with the -f option.  But the "startxemacs"
alias reads the server init file, ~/.semacs (and uses the
-iconic option to keep it hidden from view).

There is a trick to making this copacetic, because it is all too
easy to accidentally kill the server.  All it takes is C-x C-c
when only one client is running, and the server process is gone.
That key sequence is probably a reflex that can't be undone for
many Emacs users...

Here is the magic in ~/.semacs (which works with both Emacs and
XEmacs, even though I normally only use XEmacs):

 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;
 ;;; Load these modules to provide symbol definitions for compilation
 ;;;

 (eval-when-compile
   (when (featurep 'xemacs)
     (defun current-frame () "dummy to quiet XEmacs byte-compiler" ()))
   (require 'gnuserv))

 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;
 ;;;  Setup for running gnuserv, then run it
 ;;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

 ;; for GNU Emacs only
 (unless (featurep 'xemacs)
   (setq gnuserv-frame (current-frame)))

 ;;;
 ;;;  Start up the gnu edit server process
 ;;;
 (gnuserv-start)

 ;;;
 ;;;  disallow exiting from a command  (menu option only)
 ;;;
 (defun do-exit ()
   "Exits Emacs or an Emacs client"
     (interactive)
   (if   (gnuserv-running-p)
       (if (eq gnuserv-clients nil) (delete-frame) (gnuserv-edit))))

 (define-key ctl-x-map "\C-c" 'do-exit)

 ;;; end of file

Note the remapping of C-x C-c in a way that will kill off the frame
that a client process is displayed in, but will never kill the server
process itself.

However, that isn't a perfect solution.  It has a quirk that has
just never bothered me enough to cause an effort at fixing it.
When the client is invoked with a file argument on the command
line, and then while the C-x C-f command is used to view another
file, the results are strange.  The command C-x C-c will delete
the first buffer as you exit, but the second will remain buffered
by the server (the client disclaims ownership, so if it was modified,
on exit the client will complain and it has to be either saved or
killed with a kill-buffer command, C-x K).

If the second file, while still buffered by the server, is then
modified some other way (archive it with rcs, for example), the
next time the emacs client is invoked it will ask what to do
about this buffer associated with a file that has been modified
on disk.  Answering that it is okay to kill it will cause the
client to *exit*!  It does delete that buffer, so the client can
be immediately invoked again with the same command line and all
will be fine.  Annoying, but not a show stopper.

Anyway, that's an overall configuration that works for me, in part
because I don't turn computers off...

-- 
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com