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: Tue, 7 Nov 2006 22:59:17 +0100 Message-ID: References: <45507AB5.5050601@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1162936801 14146 80.91.229.2 (7 Nov 2006 22:00:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 7 Nov 2006 22:00:01 +0000 (UTC) Cc: Emacs Devel , Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 07 22:59:59 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 1GhYz7-0004TE-AM for ged-emacs-devel@m.gmane.org; Tue, 07 Nov 2006 22:59:57 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GhYz6-0004bH-Kr for ged-emacs-devel@m.gmane.org; Tue, 07 Nov 2006 16:59:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GhYyW-0004Qp-Vg for emacs-devel@gnu.org; Tue, 07 Nov 2006 16:59:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GhYyV-0004Q3-5N for emacs-devel@gnu.org; Tue, 07 Nov 2006 16:59:20 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GhYyU-0004Px-VP for emacs-devel@gnu.org; Tue, 07 Nov 2006 16:59:19 -0500 Original-Received: from [64.233.162.203] (helo=nz-out-0102.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GhYyU-0000vC-SF for emacs-devel@gnu.org; Tue, 07 Nov 2006 16:59:19 -0500 Original-Received: by nz-out-0102.google.com with SMTP id i11so1333885nzh for ; Tue, 07 Nov 2006 13:59:17 -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:content-transfer-encoding:content-disposition:references; b=NruMMYijMeD3ocHbRmGIHHcSHd6YfitKzu8I9LxWZaTidd8IsXW+La3jutPjxF+bjDyN3wcZp7PXPBJfJ3lUaJ/Et32T+QtWmWgscFYjGTPGF+VXf4jqQLB1DSrrRo99BE2cWpUXLBCow6V6Pl5lgnCAKtBC/G+SQbu8+0syqxY= Original-Received: by 10.35.51.13 with SMTP id d13mr13917000pyk.1162936757239; Tue, 07 Nov 2006 13:59:17 -0800 (PST) Original-Received: by 10.35.95.18 with HTTP; Tue, 7 Nov 2006 13:59:16 -0800 (PST) Original-To: "Stefan Monnier" In-Reply-To: Content-Disposition: inline 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:61931 Archived-At: On 11/7/06, Stefan Monnier wrote: > Obviously, my suggestion is one that aims to reduce the code complexity at > the cost of a slightly reduced choice for the user. Executing a function in `server-window' is the least complex code in `server-switch-buffer'; the burden of checking weird situations is on the user. I would rather understand if you were proposing to remove the other options. > So the question is: for what would you "use a function for `server-window'"? As I've said: to create dedicated frames for emacsclient-sent files, different of the frames I use normally. That does not depend on the name or the major-mode of the user; just on the origin. I would also use it perhaps to set local variables on these buffers (like read-only, etc.), but that could perhaps be done with `server-switch-hook'. > Would display-buffer-function work as well? Probably. But I don't see the advantage. I suppose you're going to say that `display-buffer-function' is more general, but that also means that if I want something different from normal buffers for buffers that come from emacsclient, I'm gonna be forced to move the complexity of checking from the `server-window' function to the `display-buffer-function'... > Rather something like introducing > a variable "pop-to-same-window" or something equivalent where the > "same-window" is decided by the call site rather than the buffer name. Choosing windows and frames can be complex, and the optima are quite different from one user to another. If you have an idea for pop-to-same-window or other option(s) that does not take away flexibility, I'm certainly not opposed. /L/e/k/t/u