From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?K=E1roly_Lo=22rentey?= Newsgroups: gmane.emacs.devel Subject: Re: Multi-tty design (Re: Reordering etc/NEWS) Date: Thu, 17 May 2007 17:31:10 +0200 Message-ID: <464C753E.4050008@lorentey.hu> 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> <851whfzj8r.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1252711939==" X-Trace: sea.gmane.org 1179415895 20744 80.91.229.12 (17 May 2007 15:31:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 May 2007 15:31:35 +0000 (UTC) Cc: Andreas Schwab , Dan Nicolaescu , Stefan Monnier , joakim@verona.se, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 17 17:31:32 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 1Hohwu-00029Y-FA for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 17:31:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hoi50-0002nK-Lu for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 11:39:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hoi4v-0002mV-Vf for emacs-devel@gnu.org; Thu, 17 May 2007 11:39:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hoi4v-0002lw-2N for emacs-devel@gnu.org; Thu, 17 May 2007 11:39:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hoi4u-0002lr-UL for emacs-devel@gnu.org; Thu, 17 May 2007 11:39:44 -0400 Original-Received: from ninsei.hu ([212.92.23.158]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hohwm-00069c-DT; Thu, 17 May 2007 11:31:20 -0400 Original-Received: from [192.168.36.9] (ns.netvisor.hu [195.228.79.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id 3028578F2; Thu, 17 May 2007 17:31:19 +0200 (CEST) User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) Original-Newsgroups: gmane.emacs.devel In-Reply-To: <851whfzj8r.fsf@lola.goethe.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:71257 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1252711939== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC236669E4F222323CCC049F6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC236669E4F222323CCC049F6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Kastrup wrote: > I would argue that an Emacs started with > DISPLAY=3D:0.0 emacs -display :1.0 > should export an environment variable DISPLAY=3D:1.0 to its subprocesse= s > unless explicitly overridden. This is somewhat complicated by the > situation given with > DISPLAY=3D:0.0 emacs -nw > In this case, I would still want to export :0.0 to subprocesses, and > in the case > DISPLAY=3D:0.0 emacs -nw -display :1.0 > I would suggest a non-graphical instance of Emacs exporting a DISPLAY > variable of :1.0. I do not feel this is a particularly important issue, but sure. Do people use -display often? I usually simply change DISPLAY directly. > 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. Yes, Emacs behaviour is different on different terminals according to TERM, LANG, LC_*, and others. But this isn't really a matter of having {terminal,client,frame}-local environment variables. The environment of emacsclient can remain available in `server-clients', and server.el can do the right thing even if we choose not to allow subprocesses to inherit local environments at all. So having a both UTF-8 and Latin-1 tty sessions will remain possible with or without local environment variables. >> 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. >=20 > 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. Well, there is no need to guess about that; I personally use emacsclient exactly as I would use a full-blown editor. In its current state, the branch provides a good enough approximation to this paradigm that I never notice I am not working in a local instance. > 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-!. Please try out the branch in practice. Setenv without a frame parameter has a global effect; it overrides all local environments, including the ones created by future connections. You are objecting to having different behaviour in different frames. Aren't frame-local Elisp variables equally confusing to you? >>> - 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. >=20 > 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. >=20 > AUCTeX, for example, contains code like the following: AFAICT, apart from having to replace the process-environment reference with '(environment)', the quoted code will work just fine on the multi-tty branch. > We don't want to have _any_ such code just break. Really? No incompatible change is ever allowed? Not even in a new major version? I would like to have a second opinion on that from other developers. But if that's really the case, we can still make `process-environment' have a terminal-local binding (with, I assume, DEFVAR_KBOARD), and have all existing third-party Elisp code continue to work without changes. Note that this would restrict the available designs considerably: all environment variables would have to be terminal-local, with no cherry-picking of DISPLAY. --=20 Karoly --------------enigC236669E4F222323CCC049F6 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 iD8DBQFGTHVC6eoyqA+yej8RAgpKAJ0aTySEe5cwH2gdmn0bDcpb8V2rUACeOWQx oYtAQ8ZvzRy8N2Tg4LfwBTk= =uiHd -----END PGP SIGNATURE----- --------------enigC236669E4F222323CCC049F6-- --===============1252711939== 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 --===============1252711939==--