From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Managing environments (Python venv, guix environment, etc.) Date: Mon, 25 Jul 2016 20:00:55 +0300 Message-ID: <83oa5ltzy0.fsf@gnu.org> References: <87y453sy0n.fsf@earth.catern.com> <87r3arripr.fsf@earth.catern.com> <874m7jygot.fsf@earth.catern.com> <83oa5ox21u.fsf@gnu.org> <123d2ae9-b523-5d5b-3bf8-c6e4462270b8@yandex.ru> <83vazvt8q3.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469466127 28650 80.91.229.3 (25 Jul 2016 17:02:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 17:02:07 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 25 19:02:02 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bRjGS-000281-6M for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 19:02:00 +0200 Original-Received: from localhost ([::1]:33587 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjGR-000336-89 for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 13:01:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjFs-00032n-VU for emacs-devel@gnu.org; Mon, 25 Jul 2016 13:01:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRjFp-00039m-1W for emacs-devel@gnu.org; Mon, 25 Jul 2016 13:01:24 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53378) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjFo-00039W-UT; Mon, 25 Jul 2016 13:01:20 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1062 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bRjFi-0006sB-RT; Mon, 25 Jul 2016 13:01:19 -0400 In-reply-to: (message from Dmitry Gutov on Mon, 25 Jul 2016 03:05:37 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206125 Archived-At: > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Dmitry Gutov > 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?