From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.bugs Subject: bug#6339: url-filename => "/c:/some/file.txt" Date: Wed, 09 May 2012 17:04:35 +0800 Message-ID: <87sjf94tek.fsf@gnu.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1336554307 1790 80.91.229.3 (9 May 2012 09:05:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 9 May 2012 09:05:07 +0000 (UTC) Cc: 6339@debbugs.gnu.org To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 09 11:05:06 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1SS2pW-0008KG-7I for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 May 2012 11:05:06 +0200 Original-Received: from localhost ([::1]:58419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS2pV-0000vo-IL for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 May 2012 05:05:05 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS2pN-0000u6-MH for bug-gnu-emacs@gnu.org; Wed, 09 May 2012 05:05:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SS2pH-0001dt-Ck for bug-gnu-emacs@gnu.org; Wed, 09 May 2012 05:04:57 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS2pH-0001do-9E for bug-gnu-emacs@gnu.org; Wed, 09 May 2012 05:04:51 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SS2rN-0004hm-UV for bug-gnu-emacs@gnu.org; Wed, 09 May 2012 05:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Chong Yidong Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 May 2012 09:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6339 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6339-submit@debbugs.gnu.org id=B6339.133655442018078 (code B ref 6339); Wed, 09 May 2012 09:07:01 +0000 Original-Received: (at 6339) by debbugs.gnu.org; 9 May 2012 09:07:00 +0000 Original-Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2rL-0004hX-J1 for submit@debbugs.gnu.org; Wed, 09 May 2012 05:07:00 -0400 Original-Received: from fencepost.gnu.org ([208.118.235.10]:45167 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2rI-0004hP-TH for 6339@debbugs.gnu.org; Wed, 09 May 2012 05:06:57 -0400 Original-Received: from [155.69.19.49] (port=50786 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SS2p9-0007X8-9d; Wed, 09 May 2012 05:04:43 -0400 In-Reply-To: (Juanma Barranquero's message of "Mon, 26 Jul 2010 13:50:09 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:59885 Archived-At: Ressurrecting this discussion... I just looked at the relevant code and at RFC 3986, and I think the problem is that the url object returned by url-generic-parse-url has badly named slots. That function ought to be following the RFC, instead of imposing its own interpretation of things. So the FILENAME slot, which is returned by url-filename, should really be two slots, PATH and QUERY, whose meanings are unambiguously defined in the URI spec. And there should be no expectation that the PATH part corresponds to a filename. In particular, RFC 3986 explicitly states that If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character. That is to say, the / is part of the path. Unfortunately, it's inconvenient to change the contents of the struct now, since that means changing the arglist of the url-parse-make-urlobj constructor; that constructor is already called from Tramp, and maybe other packages. So I think we should just explicitly state that the FILENAME slot is really PATH and QUERY together, and wash our hands of the matter. This also means that it should be up to callers to convert the FILENAME slot (i.e. PATH and QUERY) into proper filenames. The translation from URIs to filenames is scheme-independent anyway, so it shouldn't be handled at the level of url-generic-parse-url.