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: Re: Multi-tty design (Re: Reordering etc/NEWS) Date: Thu, 17 May 2007 15:12:52 +0200 Message-ID: <851whfzj8r.fsf@lola.goethe.zz> References: <200705131822.l4DIMtXt019128@oogie-boogie.ics.uci.edu> <85abw8o51q.fsf@lola.goethe.zz> <464835DE.3020007@lorentey.hu> <86y7jrr8rx.fsf@lola.quinscape.zz> <86lkfrr3s6.fsf@lola.quinscape.zz> <86d513r2i1.fsf@lola.quinscape.zz> <861whjr097.fsf@lola.quinscape.zz> <200705141648.l4EGmmvW007675@oogie-boogie.ics.uci.edu> <85bqgngvos.fsf@lola.goethe.zz> <200705141819.l4EIJLPr009832@oogie-boogie.ics.uci.edu> <85ps53fcm0.fsf@lola.goethe.zz> <200705142004.l4EK4DHg012188@oogie-boogie.ics.uci.edu> <85lkfrf91x.fsf@lola.goethe.zz> <200705142102.l4EL2pHK013655@oogie-boogie.ics.uci.edu> <4649D75C.2090905@lorentey.hu> <464A6144.10905@lorentey.hu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179407640 5325 80.91.229.12 (17 May 2007 13:14:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 May 2007 13:14:00 +0000 (UTC) Cc: Andreas Schwab , Dan Nicolaescu , Karoly Lorentey , joakim@verona.se, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 17 15:13:57 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 1Hofng-0003EM-O2 for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 15:13:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HofvZ-0005uU-4c for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 09:21:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HofvV-0005uM-Mc for emacs-devel@gnu.org; Thu, 17 May 2007 09:21:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HofvP-0005pb-Vx for emacs-devel@gnu.org; Thu, 17 May 2007 09:21:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HofvP-0005pR-Nd for emacs-devel@gnu.org; Thu, 17 May 2007 09:21:47 -0400 Original-Received: from mail-in-10.arcor-online.net ([151.189.21.50]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HofnF-0003II-KT for emacs-devel@gnu.org; Thu, 17 May 2007 09:13:24 -0400 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 1C8B51F527C; Thu, 17 May 2007 15:12:49 +0200 (CEST) Original-Received: from mail-in-10.arcor-online.net (mail-in-10.arcor-online.net [151.189.21.50]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id E174A27945A; Thu, 17 May 2007 15:12:48 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-048-000.pools.arcor-ip.net [84.61.48.0]) by mail-in-10.arcor-online.net (Postfix) with ESMTP id 9530C23D1E1; Thu, 17 May 2007 15:12:48 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 168FD1C4CE32; Thu, 17 May 2007 15:12:52 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Wed\, 16 May 2007 11\:41\:47 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (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:71230 Archived-At: Stefan Monnier writes: >> - At least some environment variables _must_ behave locally; >> if not client-locally, then at least terminal-locally. >> DISPLAY is perhaps the most obvious example. X clients such >> as xdvi started from Emacs must appear on the display the user >> currently works on. > > Actually, the DISPLAY environment should behave that way even > without the use of emacsclient (when you use make-frame-on-display). Agreed. But terminal-locality is all that is required (and in my opinion appropriate) here. And it is _not_ a matter of "exporting" the start _environment_, but rather of exporting the start _settings_. I would argue that an Emacs started with DISPLAY=:0.0 emacs -display :1.0 should export an environment variable DISPLAY=:1.0 to its subprocesses unless explicitly overridden. This is somewhat complicated by the situation given with DISPLAY=:0.0 emacs -nw In this case, I would still want to export :0.0 to subprocesses, and in the case DISPLAY=:0.0 emacs -nw -display :1.0 I would suggest a non-graphical instance of Emacs exporting a DISPLAY variable of :1.0. >> This is an important feature for multi-tty users and I would >> like to keep it supported. Similar variables include >> SSH_AUTH_SOCK, GPG_AGENT_INFO, AGENT_SOCKET, LANG, LC_*, and >> basically anything that may be different from login session >> to login session. > > I don't think the vars you list are particularly important. Which > version of those vars to use (the one from the emacsclient process > or from the main Emacs process) may depend from case to case. So > either choice is probably OK. Where Emacs' behavior depends on such variables, it might make sense to let them influence Emacs' behavior in terminal-local entities, and have a default export mechanism based on those terminal-local recorded settings. It would seem desirable to have parallel terminal sessions from an iso-8859-1 terminal and a utf-8 terminal into Emacs possible without getting garbled screens. In particular the ability to edit right-to-left languages in a terminal capable of RTL languages, while keeping a non RTL-capable environment for other tasks, might be one step in the course of getting Emacs usable in RTL environments. > I tend to think of emacsclient as "connect to the main Emacs > process", so I tend to expect it to work in the environment of the > main Emacs process. You seem to think of it as "pretend you're a > normal Emacs process, just quick-started", so you expect a slightly > different behavior. And I don't think that Emacs can actually be even close to satisfying the second paradigm, so there is little sense in doing a half-baked version of it and failing. >> - For the user, there is a strong sense of connection between >> an emacsclient instance and its set of frames. If emacsclient >> exits, then its frames are deleted and vice versa. C-x C-c >> kills emacsclient, not the entire Emacs process. All this >> feels very natural and fits a range of common use-cases, >> particularly the ones involving quick editing jobs from the >> command prompt. (These are the ones for which Emacs was so >> infamously not well suited before.) > > Yes, it's probably OK to use frames as an approximation of > "terminal" or "display" or "client". I disagree. If I have two frames side by side displaying the same buffer, it will be extremely confusing if using setenv in one frame will not have an effect on the other frame when calling commands with M-!. Any setenv on the same _terminal_ should certainly affect the operation on the other end. And I claim that for not display-related environment variables like "PATH", the same should hold _across_ terminals. terminal-specific variables like "DISPLAY" and possibly a subset of LC* variables should, in contrast, usually be managed terminal-locally. >> - Furthermore, to me it seems more consistent to have all >> environment variables be local than just a select few of them. > > I don't find it important, but it doesn't seem to be bad either. Disagree. It makes shell buffers behave totally unpredictable across terminals (or even worse, frames): the sequence exit RET M-x shell RET usually gets rid of environment variables set within the shell session. It would not be nice to have to guess what behavior will result. AUCTeX, for example, contains code like the following: (defun preview-set-texinputs (&optional remove) "Add `preview-TeX-style-dir' into `TEXINPUTS' variables. With prefix argument REMOVE, remove it again." (interactive "P") (let ((case-fold-search nil) (preview-TeX-style-dir (preview-TeX-style-cooked)) pattern) (if remove (progn (setq pattern (concat "\\`\\(TEXINPUTS[^=]*\\)=\\(.*\\)" (regexp-quote preview-TeX-style-dir))) (dolist (env (copy-sequence process-environment)) (if (string-match pattern env) (setenv (match-string 1 env) (and (or (< (match-beginning 2) (match-end 2)) (< (match-end 0) (length env))) (concat (match-string 2 env) (substring env (match-end 0)))))))) (setq pattern (regexp-quote preview-TeX-style-dir)) (dolist (env (cons "TEXINPUTS=" (copy-sequence process-environment))) (if (string-match "\\`\\(TEXINPUTS[^=]*\\)=" env) (unless (string-match pattern env) (setenv (match-string 1 env) (concat preview-TeX-style-dir (substring env (match-end 0)))))))))) (defcustom preview-TeX-style-dir nil "This variable contains the location of uninstalled TeX styles. If this is nil, the preview styles are considered to be part of the installed TeX system. Otherwise, it can either just specify an absolute directory, or it can be a complete TEXINPUTS specification. If it is the latter, it has to be followed by the character with which kpathsea separates path components, either `:' on Unix-like systems, or `;' on Windows-like systems. And it should be preceded with .: or .; accordingly in order to have . first in the search path. The `TEXINPUT' environment type variables will get this prepended at load time calling \\[preview-set-texinputs] to reflect this. You can permanently install the style files using \\[preview-install-styles]. Don't set this variable other than with customize so that its changes get properly reflected in the environment." :group 'preview-latex :set (lambda (var value) (and (boundp var) (symbol-value var) (preview-set-texinputs t)) (set var value) (and (symbol-value var) (preview-set-texinputs))) :type '(choice (const :tag "Installed" nil) (string :tag "Style directory or TEXINPUTS path"))) It is a straightforward manipulation of process-environment intended to work for the entire session, on variables that have nothing to do with the DISPLAY. We don't want to have _any_ such code just break. It is _not_ code that is written sloppily or making unfounded assumptions. It needs to access all environment variables obeying a given pattern and manipulate them. It does this by looping through process-environment (more exactly, a copy of it so that the exact implementation of setenv can't interfere with the loop). This is completely straightforward, not related to multi-tty-ness at all, and we don't want such usage to break. > So I'd leave it as a choice that can be determined by the > implementation. Guffah. Uh, the implementation will, _of_ _course_, determine _every_ choice. That's why we are discussing it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum