From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Multi-tty design (Re: Reordering etc/NEWS) Date: Thu, 17 May 2007 18:46:26 -0400 Message-ID: References: <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> <851whfzj8r.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 1179442019 14678 80.91.229.12 (17 May 2007 22:46:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 May 2007 22:46:59 +0000 (UTC) Cc: Andreas Schwab , Dan Nicolaescu , Karoly Lorentey , joakim@verona.se, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 18 00:46:53 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 1HookG-0004ZR-VT for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 00:46:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoosP-0001A5-Fw for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 18:55:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HoosL-00019h-UC for emacs-devel@gnu.org; Thu, 17 May 2007 18:55:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HoosK-00019U-Ns for emacs-devel@gnu.org; Thu, 17 May 2007 18:55:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HoosK-00019R-Ja for emacs-devel@gnu.org; Thu, 17 May 2007 18:55:12 -0400 Original-Received: from 18.red-83-50-230.dynamicip.rima-tde.net ([83.50.230.18] helo=alfajor.home) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hoojy-00036w-HO; Thu, 17 May 2007 18:46:46 -0400 Original-Received: by alfajor.home (Postfix, from userid 20848) id 0CFED1C151; Thu, 17 May 2007 18:46:26 -0400 (EDT) In-Reply-To: <851whfzj8r.fsf@lola.goethe.zz> (David Kastrup's message of "Thu\, 17 May 2007 15\:12\:52 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux) X-detected-kernel: Linux 2.6 (newer, 3) 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:71285 Archived-At: >> 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. Agreed, but only to the subprocesses started from frames displayed on the :1.0 display. I.e. alway export the DISPLAY on which the selected frame is displayed. > 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 case the frame is not shown on a DISPLAY but on a tty, we should probably just leave DISPLAY untouched. > DISPLAY=:0.0 emacs -nw -display :1.0 I have no idea what "-display :1.0" means when passed along with "-nw", so the behavior probably doesn't matter. >> Yes, it's probably OK to use frames as an approximation of >> "terminal" or "display" or "client". > I disagree. Actually you don't. I was saying the above with the assumption that some kind of inheritence was used so that all frames from the same terminal/client/display shared the same value. Which is the implementation he described. I don't know why he chose to use frame parameters rather than terminal-local variables, but if there's a sound reason for it, I don't think it's a terribly bad choice. > 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. >>From what Karoly says, the above is not fundamentally broken by his code, except for the need to use the `environment' function. >> 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. In my neck of the woods (language theory), when something is "determined by the implementation", it means that it's specifically left as undetermined by the spec (e.g. order of evaluation of arguments in C or Scheme). So it's not "of course". Stefan