[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Managing environments (Python venv, guix environment, etc.)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]