From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Post-22.1 development? Date: Tue, 12 Jun 2007 19:38:33 -0400 Message-ID: <87ejkgkakm.fsf@stupidchicken.com> References: <878xb05ras.fsf@stupidchicken.com> <200706101559.l5AFxBFb006829@oogie-boogie.ics.uci.edu> <86fy4yg62v.fsf@lola.quinscape.zz> <466ED07F.9000002@gnu.org> <85fy4wx1tb.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181691539 9136 80.91.229.12 (12 Jun 2007 23:38:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Jun 2007 23:38:59 +0000 (UTC) Cc: Jason Rumney , Stefan Monnier , rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 01:38:56 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 1HyFwr-0003UG-7M for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 01:38:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyFwq-0000P2-EV for ged-emacs-devel@m.gmane.org; Tue, 12 Jun 2007 19:38:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyFwo-0000Ox-Aa for emacs-devel@gnu.org; Tue, 12 Jun 2007 19:38:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyFwl-0000OR-Li for emacs-devel@gnu.org; Tue, 12 Jun 2007 19:38:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyFwl-0000OO-H2 for emacs-devel@gnu.org; Tue, 12 Jun 2007 19:38:47 -0400 Original-Received: from cyd.mit.edu ([18.115.2.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HyFwj-0000rZ-CK; Tue, 12 Jun 2007 19:38:45 -0400 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id 4D7D84E5C3; Tue, 12 Jun 2007 19:38:33 -0400 (EDT) In-Reply-To: <85fy4wx1tb.fsf@lola.goethe.zz> (David Kastrup's message of "Wed\, 13 Jun 2007 00\:09\:20 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:72726 Archived-At: David Kastrup writes: > The proposal was to have process-environment a terminal-local > variable. It is set up starting with its own values of DISPLAY and > TERM. Each last terminal-local cons-cell has a cdr of > global-process-environment. This is a "shared tail" starting with the > empty string "" (which is an environment element satisfying stringp, > but not matching any useful string pattern). setenv will use setcar > to replace an existing environment variable definition it finds in > process-environment, and will append non-existing definitions at the > end of process-environment. I think it's a bad idea to use a shared tail in this way. I can't think of anywhere else in Emacs where this kind of convoluted setup is used, and it seems to go against the way similar problems are solved elsewhere in Emacs. There are two clean ways to do this is: (i) extend process-environment so that if a symbol occurs in the list, as opposed to a string, that symbol names a list whose elements are to be used (as though they had been inserted in process-environment). Then the final element for all default values of process-environment would include the symbol `global-process-environment'; or (ii) extend process-environment so that an element of `t' means "the global value of this variable" (similar to hook variables). Either of these approaches would be backward compatible for third-party than the shared-tail idea, but IMHO the gain in cleanliness more than makes up for it.