From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: Buffer-local process environments Date: Fri, 30 Apr 2021 17:51:37 +0200 Message-ID: <87a6pfepo6.fsf@gmx.de> References: <87eeets6jf.fsf@gmail.com> <8735v99f4i.fsf@gmail.com> <87y2d1xada.fsf@gmx.de> <877dkkcjrj.fsf@gmail.com> <87tunoyzzd.fsf@gmx.de> <87eeerby1n.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11578"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Monnier , emacs-devel@gnu.org To: Augusto Stoffel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 30 17:53:53 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lcVSi-0002u5-B3 for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Apr 2021 17:53:52 +0200 Original-Received: from localhost ([::1]:38992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcVSh-0001kc-Ew for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Apr 2021 11:53:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcVQi-0000If-AM for emacs-devel@gnu.org; Fri, 30 Apr 2021 11:51:50 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:40041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcVQf-0001Pc-TI for emacs-devel@gnu.org; Fri, 30 Apr 2021 11:51:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1619797898; bh=TDOnxIYjOwy/9sSm5Vzn3tlc2C3konq3W4fnm/3fZZo=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=gF3ruyq42lPsrHipVl2hOTjqdbPnmQvWsBwnQ3o4vGApzWU26stlrkmrecYryDmDE R4noRQRcmUxvGT8jJKM7CtOMM0xfHZs/4GNoEj4yftO/a4fRWRgAWuuiiunk4DLBwX REHPzk3LOfTpPPOcU+G5apMpY6IlkpBlwjHDIFy0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([79.140.125.20]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8GQy-1lYIMU2lHc-014D4G; Fri, 30 Apr 2021 17:51:38 +0200 In-Reply-To: <87eeerby1n.fsf@gmail.com> (Augusto Stoffel's message of "Fri, 30 Apr 2021 17:19:00 +0200") X-Provags-ID: V03:K1:oIb7Mmls0ii5mGnq/vQBdKlEqFdBQ+xDPEmABAArrCAKwPM2dOW wc74rSzS7p38uvPbQ8ISgEDr+IGBPRInhVa+rjZTmxs3Ct23j8fOh1qkrrVnt0+4bCRSurZ rHTGB6lBt8M8Ay5OS39eGwomJxDZZ01uKZZ/zme2z1sm/VgZUxSKV7j32fyukINSABH7wB5 2KtLJesTo0tnWANo5GEsg== X-UI-Out-Filterresults: notjunk:1;V03:K0:H5/qzJB3HzE=:NZvaEZXmGupegBFAqqbSVe WMd4NKoM3BCoQU5RgXJpYroA16fH31DCc0IWILRLuHV6P/5DvVqaELB9QrDclPhSwEgtIEa70 NNVk22H+FhFpCQwoklqKdIIx6Hpg2a6ESSJhmpsdM7/LzcR2odqz3BMLbkytOWF43SMLxiiaY X/B2py4aO019QTqvGupgPodS+/LtWJx5pffc9TlgL0/pU1UoNUnXYSfBlGEPrKtKO2Q1UnMGE Qu7UO1r+QlJXSLDsr2MCHNapF7kyIE+bqS+saQktWK18EEldYgJTHYHAdxlROmU7kXORL9BLP kC8nEsg47csR+oRt43Dn3Z3VucMhTNTCafFNqywrBJlgMHgL1meJzKB4W9ZYpZrcAvMCCkzJb WNt+f6UYK11oXPuuQHQNBXLqWL1SuoLxCF4XQWQuo7Dp1JLGtKoCAQd0HbElXlyDkEKHEZmQQ TXKat7hr/DsBIaZZhYPyqk0ij+TnGOF0QL/wi0vlOTdmXyzjAS5aSaX+tm/kJOPsPR0ZwjkWr F3of8XenWVPV42d1xE6wy33l39rq/5yB8acLAYDRyN/InQWL+h/417c2WOdRxq+PEzWdFlFnk PXqX5S37lNdddZJaI4215LaDgvtaVRyQAyhlRaPOd78F3XTLGAKU1DUrg1Hc653fHnQJt23m/ v3Pp/G/WolnF/Yf8TGkMthzMxmZfr6kZZqujkzaDL51JiSiBGh5muKYiv7k6gvTlnEinM+gnz hrrrwoSe0rT7MqBS3EOIooZcpl9ojISZTZZ2j34WAJSzZJwGDUI0dbmcnP3JVHJUBdjCNbD2 Received-SPF: pass client-ip=212.227.17.20; envelope-from=michael.albinus@gmx.de; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268672 Archived-At: Augusto Stoffel writes: >> Because there's a lot of functions out there, which work for the local >> host, and should work also for remote hosts. See for example >> vc-git-grep, which has >> >> (let ((default-directory dir) >> (compilation-environment (cons "PAGER=" compilation-environment))) >> >> compilation-environment will be propagated to process-environment later >> on. And the setting for PAGER is needed for both local and remote >> instances of vc-git-grep. There's no special code in vc-git-grep for the >> remote case. > > Some observations: > > 1. In this case, one could call "git --no-pager" instead of relying on > an env var. > > 2. PAGER is overridden by `tramp-remote-process-environment' anyway, > right? And unlike something of the likes of PYTHONPATH, I see no > reason to customize PAGER. > > 3. If Tramp checked for the buffer-local value of process-environment > instead of the default value, then the patch for compile.el I > attached yesterday wouldn't break for remote directories, and the > let-binding trick in your example would still work. Please, it is just an example. And Tramp settings, like PAGER, have been added later on. A simple rgrep for "(process-environment" over Emacs' lisp directory shows you several other hits, some of them are good for this discussion: ./vc/vc-bzr.el97: (let ((process-environment (cons (format "BZR_LOG=%s" null-device) ./vc/vc-hg.el1432: (process-environment (cons "HGPLAIN=1" process-environment)) ./vc/vc-hg.el1507: (process-environment (cons "HGPLAIN=1" process-environment)) ./vc/vc-hg.el1522: (let ((process-environment (cons "HGPLAIN=1" process-environment)) ./vc/vc-dispatcher.el328: (process-environment (cons "LC_MESSAGES=C" process-environment)) This list is not comprehensive, of course. And again, I have no idea what is used in the wild. > So I wonder: > > A. Are there more compelling examples showing that Lisp code needs > fine-grained control over variables being exported to a remote host? > > B. There is probably a small list of variables that should be preserved > across machines, while there is an unbounded quantity of variables > that probably only make sense machine-locally (e.g., any variable > holding directory names). > > In view of 3., one could introduce the convention that the buffer-local > value of `process-environment' is for "project-local" variables, and the > let-bound value is for variables that make sense even on remote machines. > > I'm not sure this is a good proposal, though. It's a subtle rule, and > it could be quite brittle and hard to use. Honestly, the hack we have now is already annoying, at least to me. I would prefer to have something more solid to apply. > An alternative proposal is to introduce a variable > `remote-exported-variables', which anyone could set or let-bind or even > override on a connection-local basis. The value of any variable whose > name appears in this list would be passed though a remote connection. > This proposal would make a lot of sense if assumption B. is true. There is already tramp-remote-process-environment, for many years. Not much appreciated by package authors. Best regards, Michael.