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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 25 Jul 2016 03:05:37 +0300
> 
> > No, I meant that we assume these are remote files without testing,
> > e.g. that primitives which support local files, like expand-file-name,
> > don't DTRT for them.  The code is written with that assumption in
> > mind.
> 
> 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.

We have several similar examples elsewhere.

> 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 the behavior will be exactly as it is now, no?  Or
am I missing something?