From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karoly Lorentey Newsgroups: gmane.emacs.devel Subject: Re: Multi-tty design (Re: Reordering etc/NEWS) Date: Fri, 18 May 2007 19:40:53 +0200 Message-ID: <464DE525.2020508@lorentey.hu> References: <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> <464D13B1.2000903@lorentey.hu> <86wsz6o8fb.fsf@lola.quinscape.zz> <464D9449.4020108@lorentey.hu> <86hcqami9b.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1649328409==" X-Trace: sea.gmane.org 1179510081 24634 80.91.229.12 (18 May 2007 17:41:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 May 2007 17:41:21 +0000 (UTC) Cc: Andreas Schwab , Dan Nicolaescu , 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 19:41:20 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 1Hp6S6-0005M4-Fg for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 19:41:19 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hp6S4-0007rW-Pi for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 13:41:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hp6S0-0007r4-Dh for emacs-devel@gnu.org; Fri, 18 May 2007 13:41:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hp6Rz-0007qs-Hq for emacs-devel@gnu.org; Fri, 18 May 2007 13:41:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hp6Rz-0007qp-BL for emacs-devel@gnu.org; Fri, 18 May 2007 13:41:11 -0400 Original-Received: from ninsei.hu ([212.92.23.158]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hp6Rx-0004hF-PS; Fri, 18 May 2007 13:41:10 -0400 Original-Received: from [157.181.167.25] (oktnb25.inf.elte.hu [157.181.167.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id CFF5D7868; Fri, 18 May 2007 19:41:03 +0200 (CEST) User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) In-Reply-To: <86hcqami9b.fsf@lola.quinscape.zz> X-Enigmail-Version: 0.95.0 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:71331 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1649328409== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF54AE0CF9B5BE0730A43C912" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF54AE0CF9B5BE0730A43C912 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Kastrup wrote: > Karoly Lorentey writes: >>> We simply can not reach a common ground if you keep >> discarding my entire viewpoint and use-cases. >=20 > I don't see that I do. Presenting existing use-cases and problems > with them does not mean that I discard your views and approaches. It > just means that I don't consider them optimal. I want to make it clear that I'm not angry at you, just tired of the argument. I believe I have said everything I had to say on the topic of environment variables, and I simply don't think that continuing this conversation will help us advance towards a mutually satisfactory solution. My position is already available in the archives. I'll let you implement any solution that is acceptable to you. I promise I won't mind. Meanwhile, we can move on to discuss some other topics. User feedback will help us decide what (if anything) needs to be changed later. We are talking about some 50-100 lines of well-separated code, so it's not like it is going to be much work to experiment with alternative implementations. I'm sorry if it is unusual or impolite to just give up arguing like that. It is now clear to me that you care much more about how environments behave than I do. >> Explain it in a single short sentence then. > > The environment passed to processes consists of the values in the > terminal-local variable terminal-process-environment and those of the > global variable process-environment, with values in > terminal-process-environment taking priority. This sounds just peachy. Would you like to implement it? >> Clearly I won't convince you by repeating the same arguments over >> and over, and you will definitely not convince me either. >=20 > A pity if you disregard the existing typical use cases. I didn't disregard them. But they were written with strictly single-terminal sessions in mind. I feel it is entirely acceptable to require them to be changed to take advantage of the new multi-terminal feature set. But our discussion on environments really leads nowhere fast, so let's slightly change the subject, and talk a little more about the "future compatibility" of existing packages. You did not react to my observation on how all existing code that looks at `window-system' during load time breaks in multi-terminal sessions. `window-system' is frame-local on the multi-tty branch and there is *really* a lot of code that relies on it having a global binding. People whose .emacs mentions window-system are likely affected as well. Again, single-terminal sessions continue to work fine, but in multi-terminal sessions, these packages break with various levels of spectacularity. I don't think we should even attempt to implement convoluted heuristics to have these packages still somehow work fine in multi-terminal sessions. Would you agree? --=20 Karoly --------------enigF54AE0CF9B5BE0730A43C912 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTeUq6eoyqA+yej8RAiqbAJ9Vl3I3Gpk1dzs2DSlKgngomqLE+wCfcfFQ 5gaqQ6rw5lYPjeSPX+7jMWs= =Hn+A -----END PGP SIGNATURE----- --------------enigF54AE0CF9B5BE0730A43C912-- --===============1649328409== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============1649328409==--