|
From: | Dmitry Gutov |
Subject: | Re: Managing environments (Python venv, guix environment, etc.) |
Date: | Tue, 26 Jul 2016 05:08:31 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0 |
On 07/25/2016 08:00 PM, Eli Zaretskii wrote:
Couldn't that be fixed?We try, but it isn't always easy. Here's one example, from file-truename: (let ((handler (find-file-name-handler filename 'file-truename))) ;; For file name that has a special handler, call handler. ;; This is so that ange-ftp can save time by doing a no-op. (if handler (setq filename (funcall handler 'file-truename filename) done t) (let ((dir (or (file-name-directory filename) default-directory)) target dirfile) ;; Get the truename of the directory. (setq dirfile (directory-file-name dir)) ;; If these are equal, we have the (or a) root directory. (or (string= dir dirfile) (and (memq system-type '(windows-nt ms-dos cygwin nacl)) (eq (compare-strings dir 0 nil dirfile 0 nil t) t)) As you see, we only apply the MS-Windows specific treatment to files which don't have a handler, on the assumption that those which do are not subject to rules that govern local files on MS-Windows.
Maybe default handler implementation could bind the handlers alist to nil and call file-truename again.
Consider: if we just add a new defgeneric (or two) to project.el, any specialized environment implementation would either have to provide its own full project implementation (i.e. it'll be unable to use vc-project), or it'll have to define specialized implementations of these methods just for certain types of projects it knows about.Why can't the default implementation behave as if "environments" didn't exist?
Then those projects will miss out on Guix, and similar, integrations.
Then the behavior will be exactly as it is now, no?
It would. That doesn't sound optimal to me.My point is, whether a project uses Guix, or a similar tool, should be in vast majority of cases orthogonal to the type of the project (language used, frameworks, configuration file format, etc).
So far I'm inclined to believe that there should be about as many project implementations as there are project file formats (e.g. Maven, Ant, Autotools, Gradle configs, specialized formats used by other editors, etc). There's no reason to multiply that by the number of environment types we want to support.
[Prev in Thread] | Current Thread | [Next in Thread] |