From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Managing environments (Python venv, guix environment, etc.) Date: Thu, 28 Jul 2016 17:42:31 +0300 Message-ID: <83zip1rfhk.fsf@gnu.org> References: <87y453sy0n.fsf@earth.catern.com> <87r3arripr.fsf@earth.catern.com> <874m7jygot.fsf@earth.catern.com> <83oa5ox21u.fsf@gnu.org> <123d2ae9-b523-5d5b-3bf8-c6e4462270b8@yandex.ru> <87a8h7wihs.fsf@earth.catern.com> <08e690b6-56a0-1182-2560-666e3bffb2ee@yandex.ru> <87lh0qry9j.fsf@gmx.de> <87eg6hswd2.fsf@gmx.de> <87popypr3s.fsf@earth.catern.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469720374 27930 80.91.229.3 (28 Jul 2016 15:39:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2016 15:39:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 28 17:39:30 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bSnPF-0007fy-VY for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2016 17:39:30 +0200 Original-Received: from localhost ([::1]:54011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSnPB-0006Go-OS for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2016 11:39:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSmWJ-0003FQ-AZ for emacs-devel@gnu.org; Thu, 28 Jul 2016 10:42:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSmWF-0001iH-Te for emacs-devel@gnu.org; Thu, 28 Jul 2016 10:42:43 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSmWF-0001hz-QU; Thu, 28 Jul 2016 10:42:39 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3990 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bSmWE-0004He-2x; Thu, 28 Jul 2016 10:42:38 -0400 In-reply-to: <87popypr3s.fsf@earth.catern.com> (sbaugh@catern.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206210 Archived-At: > From: sbaugh@catern.com > Date: Wed, 27 Jul 2016 20:02:15 -0400 > > I do think it's best to use the same mechanism (process-file) that is > used to support remote access. > > Really, remote access is very similar to entering a different local > environment. They're different contexts in which to execute > commands. > > And consider: Much of the work in determining what is sensible to > execute in the default context, and what is sensible to execute in the > remote/custom context, has already been done for remote access. ispell > runs the spell-checker in the default context; M-x compile runs the > compile in the custom context; and so on. I think this solves the issues > Eli brought up in another mail. It may seem to you that remote access is similar to a different environment, but in fact they are very different. Environment is not a property of a file name, it is a property of a project. Moreover, past attempts I know about to use file handlers for processing local files turned out to have subtle misfeatures. Even more importantly, the _conceptual_ difference is huge, and it's bound to bite us in the long run, because people who work on the file-name handlers has the remote-access concept on their mind, and will write code that caters to those use cases, so we will sooner or later end up with code that subtly breaks in the environment use cases. So I'm very much opposed to using file-name handlers for supporting environments.