From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Terminal-local/client-local Date: Fri, 18 May 2007 22:07:21 +0200 Message-ID: <85bqghuc92.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179518848 28416 80.91.229.12 (18 May 2007 20:07:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 May 2007 20:07:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 18 22:07:27 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hp8jV-0002sT-Ab for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 22:07:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hp8jU-0005SU-Pl for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 16:07:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hp8jR-0005SN-PG for emacs-devel@gnu.org; Fri, 18 May 2007 16:07:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hp8jQ-0005SB-8j for emacs-devel@gnu.org; Fri, 18 May 2007 16:07:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hp8jQ-0005S8-55 for emacs-devel@gnu.org; Fri, 18 May 2007 16:07:20 -0400 Original-Received: from mail-in-01.arcor-online.net ([151.189.21.41]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hp8jP-00043B-Ib for emacs-devel@gnu.org; Fri, 18 May 2007 16:07:19 -0400 Original-Received: from mail-in-03-z2.arcor-online.net (mail-in-03-z2.arcor-online.net [151.189.8.15]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id 0D81D15B9C7 for ; Fri, 18 May 2007 22:07:18 +0200 (CEST) Original-Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-03-z2.arcor-online.net (Postfix) with ESMTP id F265A2D3C12 for ; Fri, 18 May 2007 22:07:17 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-072-219.pools.arcor-ip.net [84.61.72.219]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id CCB3A1C726B for ; Fri, 18 May 2007 22:07:17 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 62B1E1C4CE32; Fri, 18 May 2007 22:07:21 +0200 (CEST) User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:71338 Archived-At: I have been giving some more thought to the business of client-local settings. I remain of the opinion that we should not have both client-local and terminal-local variables. However, what is the state with regard to terminal-local variables? Here we have the following information in uni-tty Emacs: (info "(elisp) Multiple displays") Emacs treats each X server as a separate terminal, giving each one its own selected frame and its own minibuffer windows. However, only one of those frames is "_the_ selected frame" at any given moment, see *Note Input Focus::. A few Lisp variables are "terminal-local"; that is, they have a separate binding for each terminal. The binding in effect at any time is the one for the terminal that the currently selected frame belongs to. These variables include `default-minibuffer-frame', `defining-kbd-macro', `last-kbd-macro', and `system-key-alist'. They are always terminal-local, and can never be buffer-local (*note Buffer-Local Variables::) or frame-local. [...] Now _if_ we are willing to entertain the idea of having several "clients" that are supposed to be treated as semiindependent (whether or not this is supposed to include process-environment) even if they are on the same tty, what does this imply for things like "default-minibuffer-frame"? On the same text tty, there will never be more than one frame active at the same time, so whichever frame is active can make use of a minibuffer of its own. What about frames from different clients on the same X server and the other things? Different personality, same personality? I have to admit I am somewhat at a loss here. For some of these variables, the motivation to have them terminal-local appears somewhat weak since, after all, even on a single X server, only one frame will ever have focus. I am not sure I understand the motivation for all of these variables to be terminal-local, and how strong this motivation will be in every case. But _if_ we have some client-frame relationship exceeding that necessary for C-x #, then maybe the concept of terminal-local should apply to it: terminal-local variables should maybe be unique to the combination of a tty AND a client: different clients imply different terminal-local bindings, and different ttys (or active DISPLAY variables) _also_ imply different terminal-local bindings. _If_ someone can work out nice connected semantics for all those variables that are already terminal-local in trunk that work even in the case of multiple clients on the same tty, we could possibly just let my objections to client-local behavior as an added complication drop. However, I would in this case quite wish that emacsclient retained as an option "open in existing client/terminal" like the default in unitty is, and that still is available as an option in multitty. I don't believe that we have room for _both_ terminal-local and client-local variable spaces, but maybe the latter can be subsumed into the former. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum