|
From: | Dmitry Gutov |
Subject: | Re: Managing environments (Python venv, guix environment, etc.) |
Date: | Sun, 24 Jul 2016 06:26:41 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0 |
Hi Eli,I was going to comment, but this thread has run away quicker than I managed to compose a reply.
On 07/23/2016 10:10 AM, Eli Zaretskii wrote:
Actually, I don't like to see any feature, let alone a core one, use file-name-handler-alist for local files. Lots of code in Emacs, including primitives, really handle such files as remote, so the results are likely to be incorrect and subtly broken.
We do have file-remote-p, don't we? Maybe the code in question should be fixed.
I always thought that features like this one should use and extent the infrastructure in project.el. And yet Dmitry is silent in this discussion. What am I missing?
I don't know exactly if project.el is the best place for it. Maybe we should see how well environment.el works as a separate feature, and if that makes sense, incorporate it after.
My main concern with this proposal is avoiding to have to purposefully modify "every Elisp package that runs processes". If every process call will pass through the environment dispatcher, that's bound to add some overhead. How will that affect the code that makes multiple process calls at once, such as VC? I'd like to see some numbers.
And if we base this feature on project.el right away, it will add a stricter requirement on the performance of `project-current', which is currently called at most once per user command. We could add some cache there, of course.
Alternatively, we can keep environment.el separate, and any advanced minor mode, such as EDE, would both hook into project.el and set up any necessary environment.el variables.
[Prev in Thread] | Current Thread | [Next in Thread] |