🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.help
Article #1954

SUMMARY: emacs keeps emacsclient-generated buffer?

#1954
From: Amir J Katz
Date: Tue, 15 Dec 1992 10:40
87 lines
3865 bytes
Recently, I have posted the following query:

> I've just discovered the wonders of emacsclient. One thing bothers me,
> though. When I hit 'C-x #' to signal emacsclient that I'm done with the
> buffer, the buffer is buried, not killed, even though that the corresponding
> temp file has been removed. If emacsclient is invoked again from the same
> process (say, elm), the same temp file is generated and emacs still has the
> buffer, so it asks whether I want to revert the buffer. This is a nuisance. 
> Is there a way to cause the 'C-x #' not to bury the buffer but to blow it
> away completely?

Thanks to:

Vivek Khera   <khera@cs.duke.edu>
Bruce Hoylman <bruce@advtech.uswest.com>
Ken Manheimer <klm@nist.gov>

Vivek Khera and Bruce Hoylman suggested using the gnuserv/gnuclient package.

---------------------------------------------------------
Bruce Hoylman suggested a minor fix for server.el:

Bruce> I wanted the same thing, so I made the following change.  You can
Bruce> apply this using the patch() utility:

*** /usr/local/emacs/lisp/server.el     Tue Jun  5 00:11:29 1990
--- server.el   Mon Jun  8 21:35:12 1992
***************
*** 204,210 ****
          (save-excursion
            (set-buffer buffer)
            (setq server-buffer-clients nil)))
!     (bury-buffer buffer)
      next-buffer))
  
  (defun mh-draft-p (buffer)
--- 204,211 ----
          (save-excursion
            (set-buffer buffer)
            (setq server-buffer-clients nil)))
!     (message "Killing buffer ...")
!     (kill-buffer buffer)
      next-buffer))
  
  (defun mh-draft-p (buffer)

Bruce> This simply kills the client buffer and puts out a message saying it
Bruce> is doing so instead of pushing it down the buffer stack.  Works great!

---------------------------------------------------------
Ken Manheimer offered the following:
---------------------------------------------------------
Ken> Here's the kludge i use, defined in my .emacsrc, to ease disposal of
Ken> emacsclient buffers.  I think it's sound, i've been using something
Ken> like it for a while now.  I suspect it could be implemented more
Ken> cleanly.  Then again, i suspect the server buffer management stuff
Ken> could be implemented more cleanly, but that'd certainly take a lot
Ken> more work.
                       
(load-library "server")                 ; Load it so ^X-# key can be overriden.

(global-set-key "\C-x#" 'my-server-edit)

(defun my-server-edit (arg)
 "Like server-edit, but a bare ^U repeat count (= 4) means kill the buffer,
too.  Any other (or no) repeat count behaves just as server edit
normally would."
 (interactive "p")
 (let ((target-buffer
        (if (and (= arg 4) server-buffer-clients)
            (current-buffer))))
   (server-edit)
   (if target-buffer
       (kill-buffer target-buffer))
   )
 )

---------------------------------------------------------
I've implemented Bruce Hoylman's solution - just copied server.el to
my-server.el in my emacs programs directory, made the fix and load
'my-server' instead of 'server'. Works great.
-- 
/* ----------------------------------------------------------- */
/*  Amir J. Katz             |   amir@matis.ingr.COM           */
/*  System Specialist        |   Voice:  +972 52-584684        */
/*  SEE Technologies Ltd.    |   Fax:    +972 52-543917        */
/* ............ Solaris 2.0 - The Final Frontier ? ........... */
Technical Details
Message-ID: <9212150840.AA26541@simpson.ingr.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!matis.INgr.COM!amir

Show Full Headers
Complete Article Headers
Newsgroups: gnu.emacs.help
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!matis.INgr.COM!amir
From: amir@matis.INgr.COM (Amir J Katz)
Subject: SUMMARY: emacs keeps emacsclient-generated buffer?
Message-ID: <9212150840.AA26541@simpson.ingr.com>
Sender: daemon@cis.ohio-state.edu
Reply-To: amir@matis.ingr.com
Organization: SEE Technologies Ltd.
Date: Tue, 15 Dec 1992 10:40:25 GMT
Lines: 87