From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Managing environments (Python venv, guix environment, etc.) Date: Fri, 29 Jul 2016 14:42:26 -0400 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469817672 7207 80.91.229.3 (29 Jul 2016 18:41:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 18:41:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 29 20:41:03 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 1bTChz-0000wB-Qi for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 20:40:31 +0200 Original-Received: from localhost ([::1]:32840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCht-0006Rw-PK for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 14:40:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTChn-0006Rq-MV for emacs-devel@gnu.org; Fri, 29 Jul 2016 14:40:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTChj-0005eF-IO for emacs-devel@gnu.org; Fri, 29 Jul 2016 14:40:18 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:34173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTChj-0005Z3-B6 for emacs-devel@gnu.org; Fri, 29 Jul 2016 14:40:15 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bTCha-0000in-6S for emacs-devel@gnu.org; Fri, 29 Jul 2016 20:40:06 +0200 Original-Received: from modemcable222.169-23-96.mc.videotron.ca ([96.23.169.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2016 20:40:06 +0200 Original-Received: from monnier by modemcable222.169-23-96.mc.videotron.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2016 20:40:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 44 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: modemcable222.169-23-96.mc.videotron.ca User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:MLwMaEh9FVJV+eOXhBisHhzfZsM= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:206227 Archived-At: > I do think it's best to use the same mechanism (process-file) that is > used to support remote access. Fully agreed. Which is why I thought the file-name-handler-alist was probably a good way to do it. It's true that there are places where file-name-handlers are misused, so I understand Eli's concerns, but I'm not as worried about it as he is: - as long as you don't use "environments" nothing should be affected, so if there are bad interactions, they will only show up when you use the new feature. - we already have the tools to fix those interactions (such as `file-remote-p'). - we already have other non-remote file-name-handlers (jka-compr, and /: come to mind, and you could argue that some uses of /su: and /sudo: fall in the same category), so it's not a new problem. - if we bump into problems, these are probably problems that also affect other uses, so we should fix them anyway. This said, maybe it would work better to add environment support directly to process-file and start-file-process (and anywhere else that needs it) rather than use file-name-handler-alist. I'm not worried about the performance impact on process-file and friends, since it shouldn't affect that performance any more than file-name-handler-alist already affects it and it should only affect it when environments are actually used (and even in that case, the impact should be dwarfed by the time it takes to fork, set things up, exec, ...). > Perhaps instead of inserting regular filenames into > file-name-handler-alist, environment.el should use filenames with a > custom prefix (like "/?" or something) and add a new handler for > filenames with that prefix. That would solve the problem of failing to catch the environment name because an alias was used, indeed. OTOH if those environments already exist outside Emacs and are already associated with existing directories outside Emacs, it would be a lot more convenient for the user to be able to use those directories directly instead of having to use a special /?... syntax (with the added burden of having to tell Emacs which env corresponds to which dir, ...). Stefan