🚀 go-pugleaf

In <Apr.8.14.59.37.1991.3090@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes:

>I use epoch's emacsclient for my EDITOR variable, and it works fairly
>well, but after a while it will start not destroying the server window
>when I ^X#.  Around the same time, it starts asking me if I want to
>revert buffers.  Does anyonee else have this problem, and if so, are
>there any solutions other than restarting epoch?

Did you by accident ask it to edit a file that doesn't exists?  Maybe that
has nothing to do with it, but if there is already a buffer existing for a
file that ther server is asked to edit, it will ask these questions.  Try
deleting any buffers that have the same name as the file to be edited or
any other buffers that you see no reason they should be there.

I use gnuserv/gnuclient and have not seen this problem, but one of our
new epoch users had similar symptoms when first trying to use gnuclient.
---
Ken Laprade			INTERNET: laprade@trantor.harris-atd.com
Harris Corporation 		Usenet:  ...!uunet!x102a!trantor!laprade
PO Box 37, MS 3A/1912		Voice: (407)727-4433
Melbourne, FL 32902		FAX: (407)729-3363

In <Apr.8.14.59.37.1991.3090@morley.rutgers.edu> purtill@morley.rutgers.edu (Mark Purtill) writes:

>>I use epoch's emacsclient for my EDITOR variable, and it works fairly
>>well, but after a while it will start not destroying the server window
>>when I ^X#.  Around the same time, it starts asking me if I want to
>>revert buffers.  Does anyonee else have this problem, and if so, are
>>there any solutions other than restarting epoch?

We are running a similar setup and have done some analysis of this
problem. emacsclient determines that it is time to go way when the
screen being shutdown is the same name as the one it started. This
messes us up considerably because we are also using maintain-titles.el
which changes the screen title to match the file currently displayed
in the screen (we didn't like all windows named Server Screen). As 
soon as the name changes, emacsclient never terminates. The revert
problem is because epoch (and emacs) remember files as buffers once
they are initially read up. This happens particularly with things like
elm or nn where temp files have names like nn.process_number or snd.process_number.
The first time you use elm and send mail all is well. The next time you
get the revert message and you need to answer yes to make things work right.

I don't have a full cure for these problems. I have made some changes which
alleviate them (but cause other problems). emacsclient now always goes 
away because I make it exit immediately rather than waiting for the ^X#
data to come back. This fixes the hung windows but messes up things like
nn that figure that when the editor returns, editing must be complete
(not so here because emacsclient finishes immediately). Clearly not a
long term viable solution but I get by temporarily telling nn to use
emacs -nw for my editor. elm is happy since I have to explicitly tell it
to send before it reads up the edit file. As soon as I have some time
I plan to go back and try to find the correct solution and allow the
emacsclients to hang around. 

As far as the revert buffer, I added a kill-buffer to the ^X# code. 
This gets rid of things at the cost of reloading them next time.
However, you get other problems if you ever open a second screen on
the same buffer. The kill-buffer wipes the single buffer pointed to
by both screens leaving epoch in a very "upset" state that requires
stopping it and restarting it. A fix to this will require determining
that there are multiple screens pointing to the same buffer. Probably
doable when I have some time.
--
Richard R. Ragan   rrr@svl.cdc.com    (408) 496-4340 
Control Data Corporation - Silicon Valley Operations
5101 Patrick Henry Drive, Santa Clara, CA 95054-1111