From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ludwig, Mark" Newsgroups: gmane.emacs.help Subject: RE: point of "buffer still has clients" message Date: Wed, 27 Nov 2013 15:18:47 +0000 Message-ID: References: <529301AA.7070508@poczta.onet.pl> <83eh64beag.fsf@gnu.org> <52959FFE.4060703@poczta.onet.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1385566792 17318 80.91.229.3 (27 Nov 2013 15:39:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Nov 2013 15:39:52 +0000 (UTC) Cc: "help-gnu-emacs@gnu.org" To: Ian van der Neut , Jarek Czekalski Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Nov 27 16:39:57 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VlhDY-0000cT-OA for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Nov 2013 16:39:56 +0100 Original-Received: from localhost ([::1]:36474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlhDY-0004Uk-CI for geh-help-gnu-emacs@m.gmane.org; Wed, 27 Nov 2013 10:39:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlhDD-0004Ud-Ru for help-gnu-emacs@gnu.org; Wed, 27 Nov 2013 10:39:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlhD5-0007GG-Si for help-gnu-emacs@gnu.org; Wed, 27 Nov 2013 10:39:35 -0500 Original-Received: from usslmhub002.ugs.com ([134.244.32.85]:18663 helo=ugs.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlhD5-0007Fz-MN for help-gnu-emacs@gnu.org; Wed, 27 Nov 2013 10:39:27 -0500 Original-Received: from USSLMMBX003.net.plm.eds.com ([169.254.2.160]) by USSLMHUB002.net.plm.eds.com ([134.244.32.85]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 09:18:49 -0600 Thread-Topic: point of "buffer still has clients" message Thread-Index: AQHO6bNVSWg82jOZOU6QpLhqUET9K5o3rhkHgAFoqgCAABOjgIAAB7JA In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.244.20.130] X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 X-Received-From: 134.244.32.85 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:94676 Archived-At: > From: Ian van der Neut, Wednesday, November 27, 2013 2:43 AM >=20 > For what it's worth, my use case where I run into this message is as > follows: >=20 > I have a function: >=20 > (defun kill-buffer-delete-frame () > "Kill the current buffer and delete the frame its in." > (interactive) > (if (kill-buffer) (delete-frame)) > ) >=20 > And a key bound to it: > (global-set-key (kbd "C-c c") 'kill-buffer-delete-frame) >=20 > 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 i= n > that function to get rid of it? From the server-edit documentation it see= ms > 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, -and- > On Wed, Nov 27, 2013 at 8:32 AM, Jarek Czekalski wrote: >=20 > > > > W dniu 2013-11-26 16:55, Barry Margolin pisze: > > > > When you have EDITOR set to most editors, the client starts a new edit= or > >> 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 runni= ng > >> after you save the file. Emacsclient is waiting for a message from ema= cs > >> 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 durin= g > > 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 t= hat > > 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 prompt. 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? Thanks, Mark