From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.devel Subject: Re: Buffer-local process environments Date: Fri, 30 Apr 2021 17:19:00 +0200 Message-ID: <87eeerby1n.fsf@gmail.com> References: <87eeets6jf.fsf@gmail.com> <8735v99f4i.fsf@gmail.com> <87y2d1xada.fsf@gmx.de> <877dkkcjrj.fsf@gmail.com> <87tunoyzzd.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16093"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cc: Stefan Monnier , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 30 17:20:09 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 1lcUw2-00042m-Qp for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Apr 2021 17:20:06 +0200 Original-Received: from localhost ([::1]:33448 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcUw1-0002Ql-Tv for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Apr 2021 11:20:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcUv4-0001XO-9w for emacs-devel@gnu.org; Fri, 30 Apr 2021 11:19:06 -0400 Original-Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]:41620) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lcUv2-0007J6-Al for emacs-devel@gnu.org; Fri, 30 Apr 2021 11:19:06 -0400 Original-Received: by mail-ej1-x636.google.com with SMTP id zg3so24213144ejb.8 for ; Fri, 30 Apr 2021 08:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Hm1eZ/l8W4WQznyJHwAVPik0VU2Shv6z3qouadWg0qU=; b=TzWobH8JCLNUBho2wB1rtD7SjlqK6Qq/j2OnIo9c782PAwpa2NVk57sEFMq3Si4IIr lG2RgMQ1VFb+/cyV6HdMJEeoNIt3aGxE+19QV5NSgw53wnBlyUXKPrjoH2jPvaDMLTDP FjkeTm21/zCPv3CrOZxXCJd7k5PEJfAmu8tXM443OA3I9OsnmlECs93k6Ev3aRIewF45 lrx6pybBXnU4LFz2HFljzj955KPXW6dI/BKNEDxBtmykNbpb5bQMeReDo8xGkDIzHWu/ 2iiMW76V34stXX0sOOuG4Ay0JgpfrNNcRvrk1VMJqE9GrdpzJdvFDPXQAGC44OwfACdp ogaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Hm1eZ/l8W4WQznyJHwAVPik0VU2Shv6z3qouadWg0qU=; b=sHI6ENMR3WtVPxHKA8ZrDTnfs6zJmnQj5ZXzvSKFMhUCWaFzNHdoa8JRGTd/aqcHzB LsM2YskNZnWSwdrYgPkF4QZPNpmYI30p6iJxbjQWc7M4laA2C+zKGU5X1o96pIjif1Eh Z0L6YGD9HbLLKVUaJfCG9wE7f501DSAVG1fOap6AlUdW8zIXcAXJJbiCiMnKsuIf7q7q Jgou4JfxcfGD+IvGtqbYK5uRVgDxM25do/D4PkWqvI32GP5X8m13+5onZb6jVmK/ydLn ZJIQdkYtCTeqYLJyy5sLTmI8BSLjtVRgIRFHXqpUCjJYrBFDPiIsphAX8exJf+cuswWW gBOw== X-Gm-Message-State: AOAM532nrd9mgaAXoj+moCH5MDyra6UDl63pooX36HE79z5N4MBgDnlL KYlTz9IN/oy6qccsMapz4/cCVj1VGUZPcg== X-Google-Smtp-Source: ABdhPJz2aNTs+n8paJS3F2uSQgoPiXDCvuDCmzTnnFJyqs5+QZ0pOxFk0ASc1h3pro2Rw826V8L8gA== X-Received: by 2002:a17:906:32ce:: with SMTP id k14mr5107460ejk.27.1619795942536; Fri, 30 Apr 2021 08:19:02 -0700 (PDT) Original-Received: from ars3 ([2a02:908:2211:8540::68a]) by smtp.gmail.com with ESMTPSA id re14sm2191348ejb.20.2021.04.30.08.19.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Apr 2021 08:19:01 -0700 (PDT) In-Reply-To: <87tunoyzzd.fsf@gmx.de> (Michael Albinus's message of "Fri, 30 Apr 2021 09:48:38 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=arstoffel@gmail.com; helo=mail-ej1-x636.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:268668 Archived-At: > 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. 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. 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.