From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names. Date: Wed, 05 Feb 2014 16:53:51 -0500 Message-ID: References: <83ob2q4nbv.fsf@gnu.org> <83k3de41sc.fsf@gnu.org> <83iosx4iid.fsf@gnu.org> <83txcg3fle.fsf@gnu.org> <83lhxs2mru.fsf@gnu.org> <837g9a3kmb.fsf@gnu.org> <83vbwu1tk2.fsf@gnu.org> <83r47i1acs.fsf@gnu.org> <83ha8d1r1c.fsf@gnu.org> <83d2j11ggo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391637251 9183 80.91.229.3 (5 Feb 2014 21:54:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 21:54:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 22:54:18 2014 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 1WBAQA-0006dX-8o for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 22:54:14 +0100 Original-Received: from localhost ([::1]:33410 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBAQ9-0001eG-Qr for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 16:54:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBAQ1-0001e8-5j for emacs-devel@gnu.org; Wed, 05 Feb 2014 16:54:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBAPu-0002jK-Uo for emacs-devel@gnu.org; Wed, 05 Feb 2014 16:54:05 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:60593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBAPo-0002iK-7J; Wed, 05 Feb 2014 16:53:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZBG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GDLEYkAmRCgOIYZhogzGBXoMV X-IPAS-Result: Av4EABK/CFFFpZBG/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GDLEYkAmRCgOIYZhogzGBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46872159" Original-Received: from 69-165-144-70.dsl.teksavvy.com (HELO pastel.home) ([69.165.144.70]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Feb 2014 16:53:51 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 5F65160063; Wed, 5 Feb 2014 16:53:51 -0500 (EST) In-Reply-To: <83d2j11ggo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Feb 2014 21:56:23 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169424 Archived-At: >> That look reasonable (and didn't involve any remote connection or any >> such problem). > How is the 2nd one reasonable? Why shouldn't it be? It's in a context where url-handler-mode is deactivated, so Emacs has no reason to presume that it's a URL. > It means we will pass it through > expand-file-name, Which might be the right thing to do. > (expand-file-name "http://foo.com/wherever/index.html") > => "d:/gnu/bzr/emacs/trunk/http:/foo.com/wherever/index.html" If d:/gnu/bzr/emacs/trunk/http:/foo.com/wherever/ exists, then I'd argue it was the right thing to do. >> And faccess("http://foo.com/wherever/") should presumably tell you that >> dir doesn't exist. So it behaves just as well as the current code. > By sheer luck, if you ask me. The name *is* ambiguous. The only reason such ambiguity is frequent and non-problematic is because conflicts rarely arise. So I don't consider this to be luck. It's basically by design (design of the URL name space). >> The connection between the core problem of detecting the case of >> (w32-shell-execute "dir/file") and the check of file-name-handlers is >> really non-obvious. > If DOCUMENT doesn't have file handlers, it is more likely to be a > local file or directory. The correlation is weak. I don't think this heuristic is worth much if anything in this context. > I don't see how your proposal is simpler than what's already there, or > better, sorry. It's better because all the checks are *directly* related to the problem at hand: detecting non-absolute file names which include a directory component. If you only care about simpler, then we can just remove the file-name-handler check and only rely on the faccess check. That should work just as well. Stefan