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: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names. Date: Wed, 05 Feb 2014 21:56:23 +0200 Message-ID: <83d2j11ggo.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1391630199 18608 80.91.229.3 (5 Feb 2014 19:56:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Feb 2014 19:56:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 05 20:56:46 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 1WB8aS-0005os-0q for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 20:56:44 +0100 Original-Received: from localhost ([::1]:32984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB8aR-0004Jr-Kx for ged-emacs-devel@m.gmane.org; Wed, 05 Feb 2014 14:56:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB8aJ-0004JG-MU for emacs-devel@gnu.org; Wed, 05 Feb 2014 14:56:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WB8aE-0006ay-Rf for emacs-devel@gnu.org; Wed, 05 Feb 2014 14:56:35 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:38466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WB8aE-0006ZD-F0 for emacs-devel@gnu.org; Wed, 05 Feb 2014 14:56:30 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N0J00G00GKMPU00@mtaout26.012.net.il> for emacs-devel@gnu.org; Wed, 05 Feb 2014 21:55:19 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0J008MBGO6G280@mtaout26.012.net.il>; Wed, 05 Feb 2014 21:55:19 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:169423 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Wed, 05 Feb 2014 14:09:36 -0500 > > > (file-name-directory "http://foo.com/wherever/index.html") > > => "http://foo.com/wherever/" > > (file-name-absolute-p "http://foo.com/wherever/index.html") > > => nil > > That look reasonable (and didn't involve any remote connection or any > such problem). How is the 2nd one reasonable? It means we will pass it through expand-file-name, which gives the following BS: (expand-file-name "http://foo.com/wherever/index.html") => "d:/gnu/bzr/emacs/trunk/http:/foo.com/wherever/index.html" > 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. > >> - we don't check file-name-handlers > > Why is that a good idea? If a file name has a handler, any success in > > faccess etc. can only be a (rare) coincidence. > > 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. > >> - we only check (faccess dir) rather than (faccess file), and only if > >> there's a "dir". > > What is "dir" here? > > See my sample code: (file-name-directory file) > > >> - we don't bother with any of it if the file is already absolute. > > See above: deciding whether it is absolute is not easy. > > I think we only need to use w32's own notion of "absolute". But using > file-name-absolute-p should work as well. I don't see how your proposal is simpler than what's already there, or better, sorry.