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: Wed, 13 Jun 2007 14:19:08 -0400 Message-ID: <87vedrzpib.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> <87ejkgkakm.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181758774 11467 80.91.229.12 (13 Jun 2007 18:19:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 13 Jun 2007 18:19:34 +0000 (UTC) Cc: jasonr@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 13 20:19:33 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 1HyXRK-0005uQ-5l for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 20:19:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyXRJ-0003ob-Do for ged-emacs-devel@m.gmane.org; Wed, 13 Jun 2007 14:19:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HyXRF-0003oW-Ty for emacs-devel@gnu.org; Wed, 13 Jun 2007 14:19:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HyXRD-0003oK-HI for emacs-devel@gnu.org; Wed, 13 Jun 2007 14:19:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HyXRD-0003oH-Bn for emacs-devel@gnu.org; Wed, 13 Jun 2007 14:19:23 -0400 Original-Received: from cyd.mit.edu ([18.115.2.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HyXRB-0004RF-5Q; Wed, 13 Jun 2007 14:19:21 -0400 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id 5704F4E5CA; Wed, 13 Jun 2007 14:19:08 -0400 (EDT) In-Reply-To: (Richard Stallman's message of "Wed\, 13 Jun 2007 12\:22\:55 -0400") 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:72795 Archived-At: Richard Stallman writes: > 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). > > These are more elegant, but I am not sure it matters in practice. > > 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. > > I don't think so, and the reason is that this won't clean > up the code in Lisp programs at all. On the contrary, it would > complicate them. > > In other words, elegance of the mechanism is not the same thing > as simplicity of the user code. > > We use method ii for hooks, but the complexity is hidden inside > two standard functions. In this case, there are setenv and getenv. As for whether elegance of the mechanism matters in practice, consider the case where you want to (i) change a variable in the local environment and leave the global one unchanged, or (ii) ensure that a change you make in process-environment affects the global environment too. Assume you don't want to use setenv and getenv (if you do use setenv and getenv, the point is moot, since the more elegant mechanism wins anyway.) With the shared-tail mechanism, you would need to grep for the empty string "", and hope that that's really the correct marker separating the local and global lists, not a spurious marker inserted by someone else. Worse, there is no way to know for certain.