emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: Managing environments (Python venv, guix environment, etc.)
Date: Tue, 19 Jul 2016 09:39:42 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

>> Hard to tell.  Even the question is unclear to me.  The approach
>> I suggest assumes you don't need/want to make changes to what I consider
>> "core" and instead use existing hooks (in this case
>> file-name-handler-alist).  So it could be distributed via GNU ELPA,
>> for example.
> Oh, no, I do want to get this into Emacs.  Because the use of these kind
> of environments is pretty common at this point, and it would be nice if
> Emacs natively understood them in a generic way.  Then, yes, ELPA
> packages could build on that functionality to support specific
> kinds of environments. Same with the new project and xref functionality.

I don't know enough about what you'd like to put in core to comment, then.

> That seems like a decent UI. But in the manually set case, it is tricky
> to implement, because of the related buffers problem...

My impression is that this will have to be fixed case-by-case.  There is
a precedent for that, which is the handling of buffer-local settings.
E.g. vc-diff is expected to obey the vc-diff-switches settings of the
"original buffer" rather than those of the buffer where the process
runs.  So we sometimes go through the trouble to read some variables
before switching to the destination buffer.  Environments would "simply"
fall into this case.  But yes, those issues will have to fixed
one-by-one.

> Also, since this is a headline feature of GNU Guix, it would be nice to
> support it in GNU Emacs.

I'm not maintainer any more so I don't need to make those decisions.
But if I were maintainer, I'd need to see the code before I could make
a decision.


        Stefan




reply via email to

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