From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: floyd@barrow.com (Floyd L. Davidson) Newsgroups: gmane.emacs.help Subject: Re: automatic selection of emacsclient/emacs? Date: Sun, 12 Jun 2005 10:19:46 -0800 Organization: __________ Message-ID: <87is0jzbct.fld@barrow.com> References: <2cydneqEPbdzxTvfRVn-uw@speakeasy.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1118600157 31498 80.91.229.2 (12 Jun 2005 18:15:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 12 Jun 2005 18:15:57 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jun 12 20:15:47 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DhWzb-0007gm-M7 for geh-help-gnu-emacs@m.gmane.org; Sun, 12 Jun 2005 20:15:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DhX4C-00027z-Vk for geh-help-gnu-emacs@m.gmane.org; Sun, 12 Jun 2005 14:20:17 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-03!sn-xit-08!sn-post-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: gnus 5.10.6/XEmacs 21.4.15/Linux 2.6.5 Cancel-Lock: sha1:HKzaiBVfR1k4ryRMGgl5E0JLP7A= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 163 Original-Xref: shelby.stanford.edu gnu.emacs.help:131961 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:27431 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:27431 Dan Elliott 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 Ukpeagvik (Barrow, Alaska) floyd@barrow.com