From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Multi-tty design (Re: Reordering etc/NEWS) Date: Thu, 17 May 2007 16:02:52 -0400 Message-ID: References: <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> <464C753E.4050008@lorentey.hu> <85r6pfwfkb.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1179432285 13924 80.91.229.12 (17 May 2007 20:04:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 May 2007 20:04:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 17 22:04:44 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 1HomDL-0006P1-No for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 22:04:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HomLT-0000xt-2b for ged-emacs-devel@m.gmane.org; Thu, 17 May 2007 16:13:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HomLO-0000xS-IP for emacs-devel@gnu.org; Thu, 17 May 2007 16:13:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HomLK-0000xC-Uo for emacs-devel@gnu.org; Thu, 17 May 2007 16:13:02 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HomLK-0000x9-QN for emacs-devel@gnu.org; Thu, 17 May 2007 16:12:58 -0400 Original-Received: from sccrmhc14.comcast.net ([63.240.77.84]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HomDC-0000IY-4g for emacs-devel@gnu.org; Thu, 17 May 2007 16:04:34 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (sccrmhc14) with ESMTP id <200705172002420140057lfie>; Thu, 17 May 2007 20:02:43 +0000 Original-Received: from [69.25.196.100] (fwoosh.raeburn.org [69.25.196.100]) by raeburn.org (8.12.11/8.12.11) with ESMTP id l4HK2gF0013027; Thu, 17 May 2007 16:02:42 -0400 (EDT) In-Reply-To: <85r6pfwfkb.fsf@lola.goethe.zz> X-Mailer: Apple Mail (2.752.2) X-detected-kernel: NetCache Data OnTap 5.x 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:71265 Archived-At: On May 17, 2007, at 13:00, David Kastrup wrote: > "K=C3=A1roly L=C5=91rentey" writes: >> David Kastrup wrote: > > >>> 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. If the code is maintained outside of the Emacs distribution, and =20 doesn't drop Emacs 21/22 support immediately, aren't we looking at: (if (fboundp 'environment) (environment) process-environment) or something like that? Or a situation where multiple package =20 developers conditionally defines "environment" if it's not already =20 defined? If we already had a major release or two with an "environment" =20 function, and flag process-environment references as obsolete, =20 telling people to just use "environment" might be more reasonable. > "Apart from having to replace" means a regression. It means a documented incompatible change, which is not necessarily =20 the same thing. > >>> 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. > > In my opinion, a new feature in connection with ttys should, if at > all, break only code that is also connected with ttys. That is > expectable breakage. The current implementation breaks pretty much > everything that works with environments. The more I read about it, the more it seems that the multi-tty code =20 is changing the concept of an Emacs editing session, so I wouldn't =20 expect the changes to be confined to tty handling. I haven't decided yet what I think the multi-tty code should do =20 regarding environments, but for years I was using gnudoit to invoke =20 make-frame-on-display with $DISPLAY and a handful of frame settings =20 derived from environment variables, combined with hacks to update the =20= environment when switching frames, so I definitely think some =20 environment variables should be easy to switch based on where you're =20 currently coming from. (I'm intentionally avoiding "client" and =20 "frame" here.) And if it's not all environment variables, then it =20 should be an easily-changed list. Now, though, I use the Mac version a lot, so remote access went =20 away... until now; multi-tty seems like a good step in the right =20 direction. I'm still hoping for X11 as well as Carbon in the same =20 process though. :-) (Yes, I could use X11 on the Mac display, but =20 the Carbon UI feels better integrated into the system.) Ken