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: Fri, 18 May 2007 09:36:48 +0200 Message-ID: <861whepoq7.fsf@lola.quinscape.zz> 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> <86ejlfpfdj.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179473822 23036 80.91.229.12 (18 May 2007 07:37:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 May 2007 07:37:02 +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 Fri May 18 09:37:00 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 1Hox1F-0001L1-TQ for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 09:36:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hox9Q-00072n-6a for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 03:45:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hox9M-00070z-FF for emacs-devel@gnu.org; Fri, 18 May 2007 03:45:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hox9L-00070m-1r for emacs-devel@gnu.org; Fri, 18 May 2007 03:45:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hox9K-00070j-Qr for emacs-devel@gnu.org; Fri, 18 May 2007 03:45:18 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hox17-0000Vt-ON for emacs-devel@gnu.org; Fri, 18 May 2007 03:36:50 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id JAA05298 for ; Fri, 18 May 2007 09:36:48 +0200 X-Delivered-To: Original-Received: (qmail 363 invoked from network); 18 May 2007 07:36:48 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 18 May 2007 07:36:48 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 3CFAA8F1E7; Fri, 18 May 2007 09:36:48 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Thu\, 17 May 2007 19\:11\:05 -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:71298 Archived-At: Stefan Monnier writes: > I didn't know that the MS-DOS port does make Emacs's terminal > available directly to its subprocesses, but that can be easily > accomodated. I don't know about the port actually, and it is not a matter of making the terminal available as much as the subprocess just taking it, I think. The screen memory is there, and the BIOS routine accessing it are there. How is Emacs going to keep a subprocess from using those? > This brings us back to multi-tty's handling of environments. I > think breaking backward compatibility to some extent is unavoidable > because there needs to be several different notions of environments, > such as the two mentioned above. To some extent, yes. I am fine with breaking previous terminal-related code as much as required. I am less fine with breaking anything environment-related. > I think it's a good opportunity to think hard about what > setenv/getenv/process-environment should really do and how to > extend/replace them. Your message was a good start in that > direction, but I think we should first try to imagine "what should > things be like, regardless of backward compatibility" and only > afterwards try to see how to best map it to the old interface. For everything that is not terminal-related, nothing but a single environment makes sense, I think: basically all code manipulating environments assumes this, and there is quite a bit of code that might not even get run in a terminal. Anyway, when we split environments in _any_ way, it means that processes will have to keep an idea of what terminal they belong to so that this terminal can be reselected in their process sentinels and filter functions: it is important that the process sentinel can rely on having the same environment variables for further processes started from there. Maybe this already is implemented, and maybe even in trunk: no idea. Also the environment situation seems to be ugly with regard to code being run from timers: maybe one should refrain from starting terminal-dependent processes from timers. Not being allowed to start any processes seems like overkill, but we can't rely on the terminal-related parts of it to stay around, can we? -- David Kastrup