[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: point of "buffer still has clients" message

From: Ludwig, Mark
Subject: RE: point of "buffer still has clients" message
Date: Wed, 27 Nov 2013 15:18:47 +0000

> From: Ian van der Neut, Wednesday, November 27, 2013 2:43 AM
> For what it's worth, my use case where I run into this message is as
> follows:
> I have a function:
> (defun kill-buffer-delete-frame ()
>   "Kill the current buffer and delete the frame its in."
>   (interactive)
>   (if (kill-buffer) (delete-frame))
> )
> And a key bound to it:
> (global-set-key (kbd "C-c c") 'kill-buffer-delete-frame)
> I run into this message, seemingly unnecessary when I want to kill the
> buffer and close the frame it's in. should I call server-edit somewhere in
> that function to get rid of it? From the server-edit documentation it seems
> that it only kills the buffer if it didn't exist when loaded with
> emacsclient. I run emacsclient primarily with the --no-wait option btw,


> On Wed, Nov 27, 2013 at 8:32 AM, Jarek Czekalski wrote:
> >
> > W dniu 2013-11-26 16:55, Barry Margolin pisze:
> >
> >  When you have EDITOR set to most editors, the client starts a new editor
> >> process, you edit the file, save it, and then exit the editor. The
> >> client waits for the editor to exit, then it will use the result.
> >>
> >> But when you use emacsclient, it's not so simple. Emacs keeps on running
> >> after you save the file. Emacsclient is waiting for a message from emacs
> >> telling it that it you're done, so it should exit, and then its client
> >> application can use the result. You do this with the server-edit (C-x #)
> >> command.
> >>
> >
> > Barry, that definitely helps to understand the idea. But still it's not
> > clear why the things done in server-edit command couldn't be done during
> > kill-buffer. The user request is "close the file". They shouldn't have to
> > choose between server-edit and kill-buffer.
> >
> > The user experience is as follows:
> > 1. a shortcut is bound to kill-this-buffer
> > 2. a buffer is edited throught emacsclient
> > 3. user wants to kill the buffer with the shortcut he always uses for that
> > or using "File / Close" menu option
> >
> > So far you both didn't give any justification for the confirmation
> > message. If things stay this way we should assume that this message is
> > unnecessary and should be removed.

I've been using the client-server technology for over a
decade, and I've always wondered about the value of this

When this thread started, I thought the prompt was perhaps
asking whether to notify the client that I finished editing
this file, but based on experimentation on both Windows and
Solaris, that is not the case: killing the buffer (via
(kill-buffer)) releases the client.

I wonder if the original RMS comment was long enough ago
that Emacs did not prompt before killing a buffer with
unsaved modifications...?

As it stands now, if I try to kill a buffer with unsaved
modifications, I get a prompt making me confirm that I want
to throw away the changes, which seems like enough to me.
The extra prompt because the buffer has a client waiting for
it seems redundant.  Am I missing something?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]