From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: Re: emacsclient/server finished, documentation, raising frames Date: Thu, 9 Nov 2006 02:47:27 +0100 Message-ID: References: <45507AB5.5050601@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_40794_24488174.1163036847255" X-Trace: sea.gmane.org 1163037008 18089 80.91.229.2 (9 Nov 2006 01:50:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 9 Nov 2006 01:50:08 +0000 (UTC) Cc: Emacs Devel , Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 09 02:50:01 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ghz1a-0006Q9-Hh for ged-emacs-devel@m.gmane.org; Thu, 09 Nov 2006 02:48:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ghz1a-00027w-5R for ged-emacs-devel@m.gmane.org; Wed, 08 Nov 2006 20:48:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ghz1P-00027r-3n for emacs-devel@gnu.org; Wed, 08 Nov 2006 20:48:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ghz1N-00027T-MX for emacs-devel@gnu.org; Wed, 08 Nov 2006 20:48:02 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ghz1N-00027Q-FR for emacs-devel@gnu.org; Wed, 08 Nov 2006 20:48:01 -0500 Original-Received: from [64.233.166.181] (helo=py-out-1112.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Ghz1N-0000wZ-Bm for emacs-devel@gnu.org; Wed, 08 Nov 2006 20:48:01 -0500 Original-Received: by py-out-1112.google.com with SMTP id p76so20004pyb for ; Wed, 08 Nov 2006 17:47:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CcMydcFzej3pDQbHFNM0bcNkLkQv/GPWGFpylLzPC9tKsewjooz03KUbbYh4eU2CSf72Z4VjUvuAiry1t95tygSWOjVK//dRt0PVYVjzTzUbF/CKDpykKPDgaESlVnrbrl3U7RJWuIYzu4fo7p1tdftXQdVYgie+OHoSr2H1VMY= Original-Received: by 10.35.98.6 with SMTP id a6mr581562pym.1163036847306; Wed, 08 Nov 2006 17:47:27 -0800 (PST) Original-Received: by 10.35.95.18 with HTTP; Wed, 8 Nov 2006 17:47:27 -0800 (PST) Original-To: "Stefan Monnier" In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:61975 Archived-At: ------=_Part_40794_24488174.1163036847255 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Discussion has stagnated, but still something should be done. So this is a little patch to implement what Jason proposed: an option to choose whether server.el raises the frame or not when switching to a buffer. The patch does *not* try to raise the frame in two situations: - In the weird "No server buffers remain to edit" case (which, if I understand the code correctly, only happens as a result of a user interaction, and not by calling emacsclient, so focus is not an issue).^(1) - When `server-window' is a function. It is trivial to raise the frame also in this situation (just moving the `(when server-raise-window ...)' out of the enclosing `if'), but I feel that it is better this way. If the user wants to raise the frame, he can do it easily in his function, and if not, doing it ourselves would only cause him trouble.^(2) Does anyone oppose to installing this patch and settling the issue for now? We can always redesign `server-window' and `server-switch-buffer' after the release, if needed. /L/e/k/t/u ^(1) BTW, I'd like to know the use case that makes this happen. I've had to trick Emacs into killing a server-edited buffer without server.el knowing about it to be able to trigger this part of the code. ^(2) Counterargument: if the user has a `server-window' function and doesn't want server.el raising the frame, he can set `server-raise-frame' to nil. So one way or the other is fine by me. ------=_Part_40794_24488174.1163036847255 Content-Type: application/octet-stream; name=server.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_euahd9en Content-Disposition: attachment; filename="server.patch" SW5kZXg6IGxpc3AvQ2hhbmdlTG9nDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2c3Jvb3QvZW1h Y3MvZW1hY3MvbGlzcC9DaGFuZ2VMb2csdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEwMjc4DQpk aWZmIC11IC0yIC1yMS4xMDI3OCBDaGFuZ2VMb2cNCi0tLSBsaXNwL0NoYW5nZUxvZwk4IE5vdiAy MDA2IDE5OjIyOjMzIC0wMDAwCTEuMTAyNzgNCisrKyBsaXNwL0NoYW5nZUxvZwk5IE5vdiAyMDA2 IDAxOjE4OjI3IC0wMDAwDQpAQCAtMSwyICsxLDcgQEANCisyMDA2LTExLTA5ICBKdWFubWEgQmFy cmFucXVlcm8gIDxsZWtrdHVAZ21haWwuY29tPg0KKw0KKwkqIHNlcnZlci5lbCAoc2VydmVyLXJh aXNlLWZyYW1lKTogTmV3IG9wdGlvbi4NCisJKHNlcnZlci1zd2l0Y2gtYnVmZmVyKTogVXNlIGl0 Lg0KKw0KIDIwMDYtMTEtMDggIEFsYW4gTWFja2VuemllICA8YWNtQG11Yy5kZT4NCiANCkluZGV4 OiBsaXNwL3NlcnZlci5lbA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9jdnNyb290L2VtYWNzL2Vt YWNzL2xpc3Avc2VydmVyLmVsLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMjANCmRpZmYgLXUg LTIgLXIxLjEyMCBzZXJ2ZXIuZWwNCi0tLSBsaXNwL3NlcnZlci5lbAk3IE5vdiAyMDA2IDEwOjQy OjUyIC0wMDAwCTEuMTIwDQorKysgbGlzcC9zZXJ2ZXIuZWwJOSBOb3YgMjAwNiAwMToxODowMyAt MDAwMA0KQEAgLTExMyw0ICsxMTMsMTAgQEANCiAocHV0ICdzZXJ2ZXItYXV0aC1kaXIgJ3Jpc2t5 LWxvY2FsLXZhcmlhYmxlIHQpDQogDQorKGRlZmN1c3RvbSBzZXJ2ZXItcmFpc2UtZnJhbWUgdA0K KyAgIipJZiBub24tbmlsLCByYWlzZSBmcmFtZSB3aGVuIHN3aXRjaGluZyB0byBhIGJ1ZmZlci4i DQorICA6Z3JvdXAgJ3NlcnZlcg0KKyAgOnR5cGUgJ2Jvb2xlYW4NCisgIDp2ZXJzaW9uICIyMi4x IikNCisNCiAoZGVmY3VzdG9tIHNlcnZlci12aXNpdC1ob29rIG5pbA0KICAgIipIb29rIHJ1biB3 aGVuIHZpc2l0aW5nIGEgZmlsZSBmb3IgdGhlIEVtYWNzIHNlcnZlci4iDQpAQCAtNzAzLDkgKzcw OSw3IEBADQogCSAgKGlmIChhbmQgd2luIChub3Qgc2VydmVyLXdpbmRvdykpDQogCSAgICAgIDs7 IFRoZSBidWZmZXIgaXMgYWxyZWFkeSBkaXNwbGF5ZWQ6IGp1c3QgcmV1c2UgdGhlIHdpbmRvdy4N Ci0JICAgICAgKGxldCAoKGZyYW1lICh3aW5kb3ctZnJhbWUgd2luKSkpDQotCQkod2hlbiAoZXEg KGZyYW1lLXZpc2libGUtcCBmcmFtZSkgJ2ljb24pDQotCQkgIChyYWlzZS1mcmFtZSBmcmFtZSkp DQotCQkoc2VsZWN0LXdpbmRvdyB3aW4pDQotCQkoc2V0LWJ1ZmZlciBuZXh0LWJ1ZmZlcikpDQor ICAgICAgICAgICAgICAocHJvZ24NCisgICAgICAgICAgICAgICAgKHNlbGVjdC13aW5kb3cgd2lu KQ0KKyAgICAgICAgICAgICAgICAoc2V0LWJ1ZmZlciBuZXh0LWJ1ZmZlcikpDQogCSAgICA7OyBP dGhlcndpc2UsIGxldCdzIGZpbmQgYW4gYXBwcm9wcmlhdGUgd2luZG93Lg0KIAkgICAgKGNvbmQg KChhbmQgKHdpbmRvd3Agc2VydmVyLXdpbmRvdykNCkBAIC03MzEsNSArNzM1LDggQEANCiAJICAg ICAgOzsgQWZ0ZXIgYWxsIHRoZSBhYm92ZSwgd2UgbWlnaHQgc3RpbGwgaGF2ZSBlbmRlZCB1cCB3 aXRoDQogCSAgICAgIDs7IGEgbWluaWJ1ZmZlci9kZWRpY2F0ZWQtd2luZG93IChpZiB0aGVyZSdz IG5vIG90aGVyKS4NCi0JICAgICAgKGVycm9yIChwb3AtdG8tYnVmZmVyIG5leHQtYnVmZmVyKSkp KSkpKSkpDQorCSAgICAgIChlcnJvciAocG9wLXRvLWJ1ZmZlciBuZXh0LWJ1ZmZlcikpKSkNCisg ICAgICAgICAgKHdoZW4gc2VydmVyLXJhaXNlLWZyYW1lDQorICAgICAgICAgICAgKHNlbGVjdC1m cmFtZS1zZXQtaW5wdXQtZm9jdXMgKHdpbmRvdy1mcmFtZSAoc2VsZWN0ZWQtd2luZG93KSkpKQ0K KyAgICAgICAgICApKSkpKQ0KIA0KIChkZWZpbmUta2V5IGN0bC14LW1hcCAiIyIgJ3NlcnZlci1l ZGl0KQ0K ------=_Part_40794_24488174.1163036847255 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ------=_Part_40794_24488174.1163036847255--