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: Mon, 14 May 2007 21:07:19 +0200 Message-ID: <85ps53fcm0.fsf@lola.goethe.zz> References: <4645F78F.9070406@lorentey.hu> <85y7jtc41t.fsf@lola.goethe.zz> <4646F1C6.4020709@lorentey.hu> <851whkrioc.fsf@lola.goethe.zz> <85hcqg4qxs.fsf@lola.goethe.zz> <85d5144p78.fsf@lola.goethe.zz> <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179169648 16249 80.91.229.12 (14 May 2007 19:07:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 14 May 2007 19:07:28 +0000 (UTC) Cc: Andreas Schwab , Karoly Lorentey , joakim@verona.se, emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 14 21:07:25 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 1HnftF-0002fs-3D for ged-emacs-devel@m.gmane.org; Mon, 14 May 2007 21:07:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hng11-0005v6-M0 for ged-emacs-devel@m.gmane.org; Mon, 14 May 2007 15:15:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hng0z-0005uo-7i for emacs-devel@gnu.org; Mon, 14 May 2007 15:15:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hng0y-0005ub-1o for emacs-devel@gnu.org; Mon, 14 May 2007 15:15:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hng0x-0005uY-Q9 for emacs-devel@gnu.org; Mon, 14 May 2007 15:15:23 -0400 Original-Received: from mail-in-09.arcor-online.net ([151.189.21.49]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hnft9-0004Po-MP for emacs-devel@gnu.org; Mon, 14 May 2007 15:07:20 -0400 Original-Received: from mail-in-01-z2.arcor-online.net (mail-in-12-z2.arcor-online.net [151.189.8.29]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id D5ADD17B4FA; Mon, 14 May 2007 21:07:17 +0200 (CEST) Original-Received: from mail-in-03.arcor-online.net (mail-in-03.arcor-online.net [151.189.21.43]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id A200C279455; Mon, 14 May 2007 21:07:17 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-102-247.pools.arcor-ip.net [84.61.102.247]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 54B4930A918; Mon, 14 May 2007 21:07:17 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 8B55E1C0C945; Mon, 14 May 2007 21:07:20 +0200 (CEST) In-Reply-To: <200705141819.l4EIJLPr009832@oogie-boogie.ics.uci.edu> (Dan Nicolaescu's message of "Mon\, 14 May 2007 11\:19\:21 -0700") 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:71061 Archived-At: Dan Nicolaescu writes: > David Kastrup writes: > > > Dan Nicolaescu writes: > > > > > David Kastrup writes: > > > > > > > Andreas Schwab writes: > > > > > > > > > David Kastrup writes: > > > > > > > > > >> Thanks for your input. But all other applications > > > > >> (including Emacs 22.x) run in this situation using > > > > >> either tty or DISPLAY. > > > > > > > > > > Worksforme. > > > > > > > > Current checkout of multi-tty from Savannah CVS? > > > > > > Worksforme too, current checkout of multi-tty from Savannah > > > CVS, then ./configure --prefix=..... ; make bootstrap strace > > > of src/emacs -Q -nw shows that it's using terminfo not > > > termcap. What system are you on? > > > > Ubuntu Feisty. > > I tried this on a Ubuntu Feisty machine, but that machine does not > have the X11 headers installed, so I could only compile a terminal > based emacs. > > But this emacs would say "invalid argument framep 1" at startup. I > set debug-on-error to t and run C-x 5 2. The backtrace showed that > the error is in `getenv' and it is cause by an env.el change that > YOU installed on the multi-tty branch without a ChangeLog. If you tell me where to place the ChangeLog... There is a CVS log entry. > PLEASE REVERT THE CHANGE! It is never a good idea to install changes > without testing them, and you obviously didn't. I did in a running session. Anyway, if you bother to look at the change, it does nothing except make the getenv actually do what its DOC string claims to do. So reverting the change is not the right solution. Personally, I think the arguments of getenv and setenv are completely messed up. The usual behavior for optional FRAME arguments is: If FRAME is non-nil, return the value that would be normal if FRAME were the current active frame. If FRAME is nil, return the value for the current active frame. If we want to get at some special FRAME-less variant of the environment list, one could use a special argument of "t" or something like that. But the whole concept of frame-local environment variables seems like asking for trouble to me. For example, say I have a *shell* buffer. I call emacsclient from somewhere to open either a frame or a tty and say M-x shell RET in that window. The environment variables of that shell will remain the old ones. Now I say exit RET M-x shell RET again. Depending on the frame I say this, the behavior will be different. Or not. Much worse: for sentinel processes (which have no dedicated terminal), the value of PATH that gets used will be more or less randomly decided. Then Emacs already has the concept of a "terminal" (info "(elisp) Multiple Displays"). There exist things like terminal-local variables. But we also have: A single X server can handle more than one screen. A display name `HOST:SERVER.SCREEN' has three parts; the last part specifies the screen number for a given server. When you use two screens belonging to one server, Emacs knows by the similarity in their names that they share a single keyboard, and it treats them as a single terminal. So when frames get opened on the same X screen, from an Emacs session and later from an emacsclient session, Emacs treats them as _one_ _terminal_. It does not make sense to have disparate sets of environment variables for them: if I subsequently use M-x setenv RET in one frame, I would be surprised if that setting does not propagate to the other frame. So what I would propose is that we don't touch the environment variables at all. At startup of either emacsclient or emacs itself, we read out all relevant environment variables describing the current terminal (and no other) and place them into terminal-local variables, and that's it. We don't look afterwards at them for dealing with the terminal: if the user messes with them inside of Emacs, they only affect processes started within Emacs. That way we don't get to worry about just what set of frames might or might not be affected by setting environment variables. But the current treatment of process-environment and frame-local environment variables is just fragile and asking for trouble. Since we can't actually use Emacs simultaneously from two ttys, it makes no sense to give it two identities with regard to the environment. Dealing with two ttys does not really require this amount of complication. So while I agree with Dan that my change should probably be reverted (making getenv's FRAME argument be ignored completely, in contrast to its current DOC string), it appears to me like we'd be better off if pretty much all of the env.el changes (and callers) were reverted as well, and we instead replaced the calls of (getenv "TERMCAP") and similar with references to terminal-local variables filled in at the start of Emacs and/or emacsclient. What do you think? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum