From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 06:34:02 2014 Received: (at submit) by debbugs.gnu.org; 21 Aug 2014 10:34:02 +0000 Received: from localhost ([127.0.0.1]:48769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKPgv-0005BW-Qh for submit@debbugs.gnu.org; Thu, 21 Aug 2014 06:34:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46271) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKPgt-0005BB-JQ for submit@debbugs.gnu.org; Thu, 21 Aug 2014 06:34:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKPgj-0006P9-NH for submit@debbugs.gnu.org; Thu, 21 Aug 2014 06:33:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55516) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKPgj-0006P4-KW for submit@debbugs.gnu.org; Thu, 21 Aug 2014 06:33:49 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKPgf-0001aK-1p for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 06:33:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKPga-0006Ii-HX for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 06:33:44 -0400 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:62794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKPga-0006IY-Ab for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 06:33:40 -0400 Received: by mail-wi0-f173.google.com with SMTP id f8so8445928wiw.12 for ; Thu, 21 Aug 2014 03:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=jLfY4fCDaWg7W3wycse/Ood6lqGWSaFK7hNZJJ4XLtU=; b=hB4IRESt63ui1U+NnzlK5VYHzdp0xg7gBZobBkzKJX2e5T/x+5CBfC4zTrtK4QbueC x8jvk8k8zblgDOOyVpPcZ53OS59w6itStbviIF9ZACYpP9Uk/DnTKkq1R7adIzG1NUKD IPnfH7dmadIWDrTaSMdQLcFTOEl9VuSfGbnD4tKDZgku9IhsFAR4BuiokAQ2idMucL8t 9IT3o0pU+kT017Qc71+5HfMpJAh4jATYLVN/JPtSYsFkDMtBak4At+RSAe/uy4yR2n1C G0HO5G3ss/PORF8nllWrNUklzwqkaXCljoFwbsaqtGyKVfwDGEEUjWbvmKUcsKDs3owE C0Cg== X-Received: by 10.180.218.4 with SMTP id pc4mr20392263wic.15.1408617219462; Thu, 21 Aug 2014 03:33:39 -0700 (PDT) Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id je17sm18628441wic.22.2014.08.21.03.33.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Aug 2014 03:33:38 -0700 (PDT) From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) To: bug-gnu-emacs@gnu.org Subject: 24.3.93; relative links don't work in eww and Windows 7 Date: Thu, 21 Aug 2014 11:33:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Hi maintainers, On Windows 7: emacs -Q M-x eww RET http://www.lispworks.com/documentation/HyperSpec/Front/index.htm RET Try to follow any of the relative links on the page, they point to something strange like "www.lispworks.comz" (note the final "z") which basically breaks all navigation. The `shr-url' property at point shows http://www.lispworks.comz:/documentation/HyperSpec/Front/StartPts.htm And everything indicates this is a consequence of a previous bug fix of mine for bug#17217 [1], which does not manifest itself in my Linux box. I'm pretty sure it also did not manifest itself on my old Windows XP box. In that fix, I used the function `expand-file-name' in `shr-expand-url' to compute the expanded URL for "totally relative" case of hrefs like "../something". This new bug seems to be caused by `expand-file-name' insisting on producing a valid windows pathname (with drive letter), even though it was passed the second argument DEFAULT-DIRECTORY. That is, on my Windows 7 system: (expand-file-name "../bla" "/something/else") expands to "z:/something/bla" Whereas I intented it to expand to "/something/bla". My HOME variable is set to at "z:", but unsetting it does not help either. I don't have time right now to look at the C-code for `expand-file-name'. Jo=E3o [1]: http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-04/msg00266.html In GNU Emacs 24.3.93.1 (i686-pc-mingw32) of 2014-08-15 on LEG570 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --enable-checking 'CFLAGS=3D-O0 -g3' CPPFLAGS=3D-DGLYPH_DEBUG= =3D1' Important settings: value of $LC_CTYPE: UTF-8 value of $LANG: C.UTF-8 locale-coding-system: cp1252 From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 10:05:03 2014 Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 14:05:03 +0000 Received: from localhost ([127.0.0.1]:49023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKSz8-0003GK-Bq for submit@debbugs.gnu.org; Thu, 21 Aug 2014 10:05:02 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:61200) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKSz3-0003Fj-LE for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 10:04:59 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NAN00100TLOX700@a-mtaout22.012.net.il> for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 17:04:50 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAN001EJTS2OZ50@a-mtaout22.012.net.il>; Thu, 21 Aug 2014 17:04:50 +0300 (IDT) Date: Thu, 21 Aug 2014 17:04:49 +0300 From: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 In-reply-to: X-012-Sender: halo1@inter.net.il To: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Message-id: <83wqa2aqgu.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: joaotavora@gmail.com (João Távora) > Date: Thu, 21 Aug 2014 11:33:32 +0100 > > On Windows 7: > > emacs -Q > M-x eww RET > http://www.lispworks.com/documentation/HyperSpec/Front/index.htm RET > > Try to follow any of the relative links on the page, they point to > something strange like "www.lispworks.comz" (note the final "z") which > basically breaks all navigation. > > The `shr-url' property at point shows > > http://www.lispworks.comz:/documentation/HyperSpec/Front/StartPts.htm > > And everything indicates this is a consequence of a previous bug fix of > mine for bug#17217 [1], which does not manifest itself in my Linux > box. I'm pretty sure it also did not manifest itself on my old Windows > XP box. I'm pretty sure it did happen on XP. > In that fix, I used the function `expand-file-name' in `shr-expand-url' > to compute the expanded URL for "totally relative" case of hrefs like > "../something". > > This new bug seems to be caused by `expand-file-name' insisting on > producing a valid windows pathname (with drive letter), even though it > was passed the second argument DEFAULT-DIRECTORY. That's what expand-file-name is supposed to do: it should produce a fully-qualified file name that unequivocally describes a file. That means the file name must specify the drive letter. > That is, on my Windows 7 system: > > (expand-file-name "../bla" "/something/else") > > expands to > > "z:/something/bla" > > Whereas I intented it to expand to "/something/bla". "/something/bla" is not a fully-qualified file name, not on Windows. As long as the drive letter is not specified, the file name is ambiguous. > My HOME variable is set to at "z:", but unsetting it does not help > either. I don't think it's because of HOME, since there was no "~" in the file name. I'm guessing that the default-directory of the buffer where you used that code was on the z: drive, so Emacs used that to complete the missing drive letter. > I don't have time right now to look at the C-code for > `expand-file-name'. There's nothing wrong with expand-file-name, please don't waste your time looking there. The problem is in the change you made. You cannot use expand-file-name on anything but a file name on a local filesystem, even if the "thing" you have to deal with happens to look like a file name and uses slashes as separators. expand-file-name assumes without testing that its arguments are syntactically valid local file names, and will produce invalid results if they are not. Please use url-expand-file-name instead, it does exactly what you want, and does that portably. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 11:44:03 2014 Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 15:44:03 +0000 Received: from localhost ([127.0.0.1]:49067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKUWx-0005nl-59 for submit@debbugs.gnu.org; Thu, 21 Aug 2014 11:44:03 -0400 Received: from mail-we0-f179.google.com ([74.125.82.179]:43913) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKUWt-0005n8-UQ for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 11:44:01 -0400 Received: by mail-we0-f179.google.com with SMTP id u57so9374574wes.24 for <18310@debbugs.gnu.org>; Thu, 21 Aug 2014 08:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=VGyGvh3yCDLB2r1YRwOgRUBgmOJgD5QJB0aCCJoIJIc=; b=ZnjUhGH/hf6m62+uurp+1JaJ7VB6e2RWPnfRYF7YV6YY3Cj0UUlOPULhFIHts8Pu9M cp2dLAb0kwePckbkUzUfhq2gyGMi7f9CuBa6h1UbERu16yarKpgBTDflkMVYy8tPpcVU mwRVa25Ce1OEIXFrUJf3/kmRGBwY38us1oH4H1vOa0NVsOEz9B9hpkT94BiHSPntab1V ibMLg6p924Tjp8/U9ac2LjS5tVKvfrSBAYWQTY7sIXiKmUx5xa/xcUlzJUY0+cXXq2Up TKpElCgRBFdtfVDb1ROVUc5kaBcqbr4coJ7ghTo6teVYHqZKAHpDXv8tae4HFGMU9DOR v8aA== X-Received: by 10.194.209.169 with SMTP id mn9mr4458139wjc.122.1408635833692; Thu, 21 Aug 2014 08:43:53 -0700 (PDT) Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id oz9sm16846388wjb.20.2014.08.21.08.43.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Aug 2014 08:43:52 -0700 (PDT) From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) To: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 References: <83wqa2aqgu.fsf@gnu.org> Date: Thu, 21 Aug 2014 16:43:48 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > I'm pretty sure it did happen on XP. I wasn't aware of the bug until the switch to Windows 7. Maybe I didn't use eww with relative links at all, or maybe other factors influencing `expand-file-name' weren't acting. > I don't think it's because of HOME, since there was no "~" in the file > name. I'm guessing that the default-directory of the buffer where you > used that code was on the z: drive, so Emacs used that to complete the > missing drive letter. Something other than `default-directory' seems to be influencing it. I did some tests: (let ((default-directory "/")) (expand-file-name "../" "/something/bla")) (let ((default-directory "\\")) (expand-file-name "../" "/something/bla")) =20=20=20=20 (let ((default-directory nil)) (expand-file-name "../" "/something/bla")) (let ((default-directory "")) (expand-file-name "../" "/something/bla")) All produce "z:/something". However (let ((default-directory "c:")) (expand-file-name "../" "/something/bla")) (let ((default-directory "\\\\mymachine")) (expand-file-name "../" "/something/bla")) Do produce "c:/something/" and "//mymachine/something/", respectively. Finally (let ((default-directory "\\\\")) (expand-file-name "../" "/something/bla")) Crashed the Emacs process on my machine. Can you reproduce? I don't have debuggers handy on Windows, so can't even get a backtrace. > There's nothing wrong with expand-file-name, please don't waste your > time looking there. Well, there's the fact that it crashed... but anyway I didn't say there was. I just didn't understand what it did. Now that you have explained, I do, more than before at least. But from its docstring it's not clear. I didn't understand that "canonicalize" means different for different platforms. Maybe because Emacs use of "/" on Windows is an exception I'm used to. The docstring should explain its relationship with the `default-directory' variable, which in the current version sounds like it's shadowed completely by the DEFAULT-DIRECTORY parameter. Perhaps a sentence could be added. If DEFAULT-DIRECTORY is nil or missing, the current buffer's value of `default-directory' is used. Even if DEFAULT-DIRECTORY is non-nil, `default-directory' may still be used to help canonicalize the resulting name for the current platform. If it's being influenced by anything else, it should also explain it. > Please use url-expand-file-name instead, it does exactly what you > want, and does that portably. That sounds perfectly right, but I don't have time to setup my Emacs development environment, sorry, so maybe someone else can perform the change. I think it's a bug to fix for 24.4. Jo=E3o PS: Had a look at `url-expand-file-name': isn't it doing to much for `shr-expand-url''s purposes? There seems to be an overlap between the two. Anyway for 24.4 any fix will do I guess. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 12:18:07 2014 Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 16:18:07 +0000 Received: from localhost ([127.0.0.1]:49090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKV3t-0007w1-Q3 for submit@debbugs.gnu.org; Thu, 21 Aug 2014 12:18:07 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:34085) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKV3q-0007vS-8z for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 12:18:03 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NAN00200Z6NMS00@mtaout25.012.net.il> for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 19:12:46 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAN00JSMZPAX790@mtaout25.012.net.il>; Thu, 21 Aug 2014 19:12:46 +0300 (IDT) Date: Thu, 21 Aug 2014 19:17:55 +0300 From: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 In-reply-to: X-012-Sender: halo1@inter.net.il To: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Message-id: <83lhqhbyvg.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <83wqa2aqgu.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: joaotavora@gmail.com (João Távora) > Cc: 18310@debbugs.gnu.org > Date: Thu, 21 Aug 2014 16:43:48 +0100 > > Something other than `default-directory' seems to be influencing it. I > did some tests: Like I said: Emacs uses the current drive to complete the missing drive letter. That is what you see. > Finally > > (let ((default-directory "\\\\")) > (expand-file-name "../" "/something/bla")) > > Crashed the Emacs process on my machine. It's not a crash, it's a deliberate abort. "\\\\" (i.e., 2 backslashes in a row without anything after that) is an invalid file name on Windows. Just don't do that. > The docstring should explain its relationship with the > `default-directory' variable, which in the current version sounds like > it's shadowed completely by the DEFAULT-DIRECTORY parameter. Perhaps a > sentence could be added. > > If DEFAULT-DIRECTORY is nil or missing, the current buffer's value of > `default-directory' is used. Even if DEFAULT-DIRECTORY is non-nil, > `default-directory' may still be used to help canonicalize the > resulting name for the current platform. How does that obscure hint help? It doesn't tell anything that mere mortals could understand. Once again, you are talking about semi-invalid use cases. IMO, complicating the doc string (which is not at all simple as it is) on behalf of those use cases is not TRT. > PS: Had a look at `url-expand-file-name': isn't it doing to much for > `shr-expand-url''s purposes? I have no idea, but as long as you need to resolve relative URLs, it is your friend. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 12:54:24 2014 Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 16:54:24 +0000 Received: from localhost ([127.0.0.1]:49104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKVd1-0000Sb-Nv for submit@debbugs.gnu.org; Thu, 21 Aug 2014 12:54:24 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:59663) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKVcy-0000SK-OV for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 12:54:21 -0400 Received: by mail-wi0-f175.google.com with SMTP id ho1so9005588wib.8 for <18310@debbugs.gnu.org>; Thu, 21 Aug 2014 09:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=MuUf1PL9lUv6OEpu8pDiJMgTXQIx/KMQ9ZfccZ+3Nu0=; b=vWgKjgMuCZdF2o4UQ0dC7jLK49b+Gc3W0HS6BX0Y7xPQrloU+wxkxwv21L6hwGWfup DSyxB5mrS2ea7MTK5BFp697FpQ11nLh4VqQra4nRVxFVa6z6JaRyKPC+pFBflsHlAUKE NZ1he0/bguKuIqMTfATlY3YjAusX9cNjuAdmdRu3mgogZS9E6lXh9iETZEAvtoMSjdRI E3M/kGx6IreOuJiSO15G769lgKtW0KodRmA7tZ0XdtJcbJbZlDxm6LvVPT+PEeVIeO2o NDRTuetA0AGRcaAIaenjiAvEzNZTsGmR0UaSmldaF6f5+hTgDHhQvpBn5jsbyZD+5FkW Rupw== X-Received: by 10.180.188.205 with SMTP id gc13mr11627029wic.66.1408640054796; Thu, 21 Aug 2014 09:54:14 -0700 (PDT) Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id h3sm68027486wjn.10.2014.08.21.09.54.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Aug 2014 09:54:13 -0700 (PDT) From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) To: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> Date: Thu, 21 Aug 2014 17:54:11 +0100 In-Reply-To: <83lhqhbyvg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Aug 2014 19:17:55 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> From: joaotavora@gmail.com (Jo=E3o T=E1vora) >> Cc: 18310@debbugs.gnu.org >> Date: Thu, 21 Aug 2014 16:43:48 +0100 >>=20 >> Something other than `default-directory' seems to be influencing it. I >> did some tests: > > Like I said: Emacs uses the current drive to complete the missing > drive letter. That is what you see. OK. How is the "current drive" calculated when `default-directory' is nil? >> Finally >>=20 >> (let ((default-directory "\\\\")) >> (expand-file-name "../" "/something/bla")) >>=20 >> Crashed the Emacs process on my machine. > > It's not a crash, it's a deliberate abort. "\\\\" (i.e., 2 > backslashes in a row without anything after that) is an invalid file > name on Windows. Would signalling an error be very wrong, does the process really need to be aborted? I mean unprotected code may easily lead to that invalid case. > How does that obscure hint help? It doesn't tell anything that mere > mortals could understand.=20 It mirrors the function's obscurity, so mere mortals can at least be warned of death by deliberate abort. Anyway it was meant for you to complete with enlightenment about the function's interaction with things other than `default-directory', something you didn't do.=20 And needn't do, at least for me, since at least now I know to stay away from `expand-file-name's quirks. > Once again, you are talking about semi-invalid use cases. IMO, > complicating the doc string (which is not at all simple as it is) on > behalf of those use cases is not TRT. BTW "Semi-invalid" uses, or even downright absurd use cases, are what development/testing/experimentation is all about. IMO aborting the process and not at least warning elisp users about invalid cases in the documentation is not good practice in my opinion. Jo=E3o From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 21 15:17:50 2014 Received: (at 18310) by debbugs.gnu.org; 21 Aug 2014 19:17:50 +0000 Received: from localhost ([127.0.0.1]:49153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKXrp-0004AH-29 for submit@debbugs.gnu.org; Thu, 21 Aug 2014 15:17:49 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:57127) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKXrm-0004A0-6E for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 15:17:47 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NAO00C0086WZB00@a-mtaout20.012.net.il> for 18310@debbugs.gnu.org; Thu, 21 Aug 2014 22:17:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAO00C7489EZK00@a-mtaout20.012.net.il>; Thu, 21 Aug 2014 22:17:39 +0300 (IDT) Date: Thu, 21 Aug 2014 22:17:38 +0300 From: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 In-reply-to: X-012-Sender: halo1@inter.net.il To: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Message-id: <83k361bqjx.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: joaotavora@gmail.com (João Távora) > Cc: 18310@debbugs.gnu.org > Date: Thu, 21 Aug 2014 17:54:11 +0100 > > Eli Zaretskii writes: > > >> From: joaotavora@gmail.com (João Távora) > >> Cc: 18310@debbugs.gnu.org > >> Date: Thu, 21 Aug 2014 16:43:48 +0100 > >> > >> Something other than `default-directory' seems to be influencing it. I > >> did some tests: > > > > Like I said: Emacs uses the current drive to complete the missing > > drive letter. That is what you see. > > OK. How is the "current drive" calculated when `default-directory' is > nil? There's a system call to get the "current drive", where Emacs runs. > >> Finally > >> > >> (let ((default-directory "\\\\")) > >> (expand-file-name "../" "/something/bla")) > >> > >> Crashed the Emacs process on my machine. > > > > It's not a crash, it's a deliberate abort. "\\\\" (i.e., 2 > > backslashes in a row without anything after that) is an invalid file > > name on Windows. > > Would signalling an error be very wrong, does the process really need to > be aborted? Yes. This is a deliberate trap for code either in Emacs itself or in Lisp applications that uses such invalid default-directory values. > I mean unprotected code may easily lead to that invalid case. Not "easily", no. Usually, default-directory comes from some file or buffer. But if some code does use that, we want to catch it red-handed, because there's no way to know what other damage it can do down the road. > BTW "Semi-invalid" uses, or even downright absurd use cases, are what > development/testing/experimentation is all about. IMO aborting the > process and not at least warning elisp users about invalid cases in the > documentation is not good practice in my opinion. Emacs is not mission-critical software. If it were, then I'd agree with you (I happen to develop mission-critical software for a living). From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 06:26:21 2014 Received: (at 18310) by debbugs.gnu.org; 22 Aug 2014 10:26:21 +0000 Received: from localhost ([127.0.0.1]:49313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKm32-0003Ly-4d for submit@debbugs.gnu.org; Fri, 22 Aug 2014 06:26:20 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:63661) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKm2y-0003Lg-KB for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 06:26:17 -0400 Received: by mail-wg0-f42.google.com with SMTP id l18so10177014wgh.25 for <18310@debbugs.gnu.org>; Fri, 22 Aug 2014 03:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=S1sr6nbF9F1EyNvtxOsTIntnZgN3nzh7eh3GNcG0YnA=; b=Mwa2PzPh9Dsc8gGboPKHlAkA4fZujpPQwVpS7gjY15F/5c2f5qpCWnCCM3V+3xjulP 3/0nVOj67+PDtlUC/S1H6IkjSxFaMIfZXx8cqwpl3zxHxinyTjzO+m0i0UCe2Samx/cW 8R99XrK3Iw4rE+AGTf/K3SxhXb8Zt5VlAbMdY6JRU4/03xtlg4n0AbSnKJRJ6L9ST9aT 1ndzL7gk8xr6fY5FFugEqY152Te4KYRWj+BC2UBqKZ9/RAGmgXTPIeJTmzv4O18qvmtV P5dwpec4lOvyKrwmNi6G2S4jFHAm9l+4X//4kltaXL1221vxq001qt+/ezzt5yWQGuqm nFjA== X-Received: by 10.194.6.233 with SMTP id e9mr4431930wja.29.1408703170697; Fri, 22 Aug 2014 03:26:10 -0700 (PDT) Received: from GONDOMAR.yourcompany.com (a81-84-241-129.static.cpe.netcabo.pt. [81.84.241.129]) by mx.google.com with ESMTPSA id e3sm74040861wjp.4.2014.08.22.03.26.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Aug 2014 03:26:09 -0700 (PDT) From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) To: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <83k361bqjx.fsf@gnu.org> Date: Fri, 22 Aug 2014 11:26:03 +0100 In-Reply-To: <83k361bqjx.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Aug 2014 22:17:38 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> >> Finally >> >> >> >> (let ((default-directory "\\\\")) >> >> (expand-file-name "../" "/something/bla")) >> >> >> >> Crashed the Emacs process on my machine. >> > >> > It's not a crash, it's a deliberate abort. "\\\\" (i.e., 2 >> > backslashes in a row without anything after that) is an invalid file >> > name on Windows. >> >> Would signalling an error be very wrong, does the process really need to >> be aborted? > > Yes. This is a deliberate trap for code either in Emacs itself or in > Lisp applications that uses such invalid default-directory values. But it really seems arbitrary, since (let ((default-directory "><>:\"/\|?*")) (expand-file-name "../" "/something/bla")) contains very much an invalid `default-directory' value and does not "deliberately abort". It returs "z:/something" as always (i.e default-directory is fully ignored). >> I mean unprotected code may easily lead to that invalid case. > > Not "easily", no. Usually, default-directory comes from some file or > buffer. It can very well be lexically bound to something that eventually evaluates to "////". For example to temporarily work on a directory in a Lisp program. Emacs own lisp code seems littered with (let ((default-directory ...)), just grep for it. > But if some code does use that, we want to catch it red-handed, > because there's no way to know what other damage it can do down the > road. To be clear, I fully support your "early abort" cause. But one thing is aborting the command the other thing is aborting the process. I think you should do the latter if it's the Emacs' internals that caused the (supposedly unrecoverable) error. But you should do the former if it was the user's Lisp program that provided incorrect input. I've looked at the code and expand-file-name is a woolly mammoth so maybe that's hard to do, but it would be the right thing IMO. > Emacs is not mission-critical software. If it were, then I'd agree > with you (I happen to develop mission-critical software for a living). Me too. In Lisp. But that's besides the point. Just because Emacs exists "in the hope that it will be useful" doesn't mean one shouldn't care about user's critical mission. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 06:49:03 2014 Received: (at 18310) by debbugs.gnu.org; 22 Aug 2014 10:49:03 +0000 Received: from localhost ([127.0.0.1]:49324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKmP0-0003v0-Qv for submit@debbugs.gnu.org; Fri, 22 Aug 2014 06:49:03 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:61365) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKmOw-0003uU-MR for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 06:49:00 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NAP00D00F1MBT00@a-mtaout22.012.net.il> for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 13:48:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAP00CCXFDEX650@a-mtaout22.012.net.il>; Fri, 22 Aug 2014 13:48:51 +0300 (IDT) Date: Fri, 22 Aug 2014 13:48:51 +0300 From: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 In-reply-to: X-012-Sender: halo1@inter.net.il To: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) Message-id: <83vbpkn6jw.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <83k361bqjx.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: joaotavora@gmail.com (João Távora) > Cc: 18310@debbugs.gnu.org > Date: Fri, 22 Aug 2014 11:26:03 +0100 > > > Yes. This is a deliberate trap for code either in Emacs itself or in > > Lisp applications that uses such invalid default-directory values. > > But it really seems arbitrary, since > > (let ((default-directory "><>:\"/\|?*")) > (expand-file-name "../" "/something/bla")) > > contains very much an invalid `default-directory' value and does not > "deliberately abort". It returs "z:/something" as always (i.e > default-directory is fully ignored). It's not arbitrary: "\\\\" signals a beginning of a UNC, which should have the host name and the share name following it, while the string you used above is simply random garbage. > >> I mean unprotected code may easily lead to that invalid case. > > > > Not "easily", no. Usually, default-directory comes from some file or > > buffer. > > It can very well be lexically bound to something that eventually > evaluates to "////". Then we want to catch those uses. > For example to temporarily work on a directory in a Lisp program. "\\\\" is not a directory, it's a butchered UNC. > To be clear, I fully support your "early abort" cause. But one thing is > aborting the command the other thing is aborting the process. I think > you should do the latter if it's the Emacs' internals that caused the > (supposedly unrecoverable) error. But you should do the former if it was > the user's Lisp program that provided incorrect input. Signaling an error is not prominent enough to catch the attention, it can be easily skipped, ignored, or even disabled. > I've looked at the code and expand-file-name is a woolly mammoth so > maybe that's hard to do, but it would be the right thing IMO. expand-file-name already does what is humanly possible to handle many weird cases. This one is not, and should not, be one of them. > Just because Emacs exists "in the hope that it will be useful" > doesn't mean one shouldn't care about user's critical mission. When Emacs aborts, it auto-saves, so it does care about users. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 10:39:43 2014 Received: (at 18310) by debbugs.gnu.org; 22 Aug 2014 14:39:43 +0000 Received: from localhost ([127.0.0.1]:49661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKq0F-0003WW-57 for submit@debbugs.gnu.org; Fri, 22 Aug 2014 10:39:43 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:39994) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKq0A-0003WL-N6 for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 10:39:39 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 481FA84F3C; Fri, 22 Aug 2014 10:39:38 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id C84091E5B8A; Fri, 22 Aug 2014 10:39:13 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id A1435B407A; Fri, 22 Aug 2014 10:39:13 -0400 (EDT) From: Stefan Monnier To: joaotavora@gmail.com (=?windows-1252?B?Sm/jbyBU4XZvcmE=?=) Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 Message-ID: References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <83k361bqjx.fsf@gnu.org> Date: Fri, 22 Aug 2014 10:39:13 -0400 In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1v?= =?windows-1252?Q?ora=22's?= message of "Fri, 22 Aug 2014 11:26:03 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 18310 Cc: Eli Zaretskii , 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) > To be clear, I fully support your "early abort" cause. But one thing is > aborting the command the other thing is aborting the process. I think > you should do the latter if it's the Emacs' internals that caused the > (supposedly unrecoverable) error. But you should do the former if it was > the user's Lisp program that provided incorrect input. FWIW, I fully agree. Luckily I I don't need to use an Emacs compiled for w32, but if I were to have my Emacs die from under me just because I used an incorrect default-directory, I wouldn't like it all. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 22 11:25:56 2014 Received: (at 18310) by debbugs.gnu.org; 22 Aug 2014 15:25:56 +0000 Received: from localhost ([127.0.0.1]:49668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKqix-0004dj-Sb for submit@debbugs.gnu.org; Fri, 22 Aug 2014 11:25:56 -0400 Received: from mtaout28.012.net.il ([80.179.55.184]:40660) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKqit-0004dP-S7 for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 11:25:53 -0400 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NAP00B00S4B0K00@mtaout28.012.net.il> for 18310@debbugs.gnu.org; Fri, 22 Aug 2014 18:24:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAP00B47S5F2700@mtaout28.012.net.il>; Fri, 22 Aug 2014 18:24:51 +0300 (IDT) Date: Fri, 22 Aug 2014 18:25:45 +0300 From: Eli Zaretskii Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83lhqgmtqe.fsf@gnu.org> References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <83k361bqjx.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 18310@debbugs.gnu.org > Date: Fri, 22 Aug 2014 10:39:13 -0400 > > > To be clear, I fully support your "early abort" cause. But one thing is > > aborting the command the other thing is aborting the process. I think > > you should do the latter if it's the Emacs' internals that caused the > > (supposedly unrecoverable) error. But you should do the former if it was > > the user's Lisp program that provided incorrect input. > > FWIW, I fully agree. Then we'll have to disagree. > Luckily I I don't need to use an Emacs compiled for w32 Then I submit that my opinion matters more than yours here. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 25 13:23:27 2014 Received: (at 18310) by debbugs.gnu.org; 25 Aug 2014 17:23:27 +0000 Received: from localhost ([127.0.0.1]:51927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XLxzK-0004sD-Jj for submit@debbugs.gnu.org; Mon, 25 Aug 2014 13:23:27 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:40214) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XLxzH-0004rr-Md for 18310@debbugs.gnu.org; Mon, 25 Aug 2014 13:23:24 -0400 Received: by mail-wi0-f174.google.com with SMTP id d1so2907038wiv.13 for <18310@debbugs.gnu.org>; Mon, 25 Aug 2014 10:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=h0B7+c9KMSOjZnAW7IqJIOGxcfqqTRPDnEY//yr0Xms=; b=ELXZVWmaXlFhBsnQ7fymufX+bUTJxWKGd7Nj4TccJv5jPNeDw1DIAwdVhuMs08uiyN FOtUGSBhrpT72HIyk2T/p+E2Cf5LcHg3l/Q+JhJAgyM1pv51s5X7z9stGcL2i7bAW5fV AoxlIJyMx9HOuWcJsz8ZcL6c+CCb9vngwnEbdcsi258W0PFPbUErFmAWH13o7UubZGYy SfivbvzE85LX4F1aKNpD7UmgxN6hBA+ftr2QHXWG77bdYKDlkW7ck5bUHmy0ahvh1BQ9 2PJsIijN255JdvxqPVxQ4ppaj1wrvLPEfgSV6eAJfVV+W9adhwpv8G/l5MFlHR/2EAu/ 1+cQ== X-Received: by 10.195.13.34 with SMTP id ev2mr23329634wjd.55.1408987398054; Mon, 25 Aug 2014 10:23:18 -0700 (PDT) Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by mx.google.com with ESMTPSA id pk9sm1145260wjb.16.2014.08.25.10.23.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Aug 2014 10:23:17 -0700 (PDT) From: joaotavora@gmail.com (=?iso-8859-1?Q?Jo=E3o_T=E1vora?=) To: Eli Zaretskii , monnier@iro.umontreal.ca Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 In-Reply-To: <83lhqhbyvg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 21 Aug 2014 19:17:55 +0300") References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (windows-nt) Date: Mon, 25 Aug 2014 18:23:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: >> PS: Had a look at `url-expand-file-name': isn't it doing to much for >> `shr-expand-url''s purposes? > > I have no idea, but as long as you need to resolve relative URLs, it > is your friend. Back on topic, the diff in PS seems to work. With the new calling convention, of first concatenating the car and cadr of `base', so does `expand-file-name', by the way. Can anyone verify and install it? Jo=E3o diff --git a/lisp/net/shr.el b/lisp/net/shr.el index 5844257..244d6d6 100644 --- a/lisp/net/shr.el +++ b/lisp/net/shr.el @@ -32,6 +32,8 @@ =20 (eval-when-compile (require 'cl)) (eval-when-compile (require 'url)) ;For url-filename's setf handler. + +(require 'url-expand) ; For url-expand-file-name (require 'browse-url) =20 (defgroup shr nil @@ -610,7 +612,7 @@ size, and full-buffer size." (concat (nth 3 base) url)) (t ;; Totally relative. - (concat (car base) (expand-file-name url (cadr base)))))) + (url-expand-file-name url (concat (car base) (cadr base)))))) =20 (defun shr-ensure-newline () (unless (zerop (current-column)) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 26 14:11:10 2014 Received: (at 18310) by debbugs.gnu.org; 26 Aug 2014 18:11:10 +0000 Received: from localhost ([127.0.0.1]:52726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XMLD3-0003Vr-OQ for submit@debbugs.gnu.org; Tue, 26 Aug 2014 14:11:10 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:35692 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XMLD1-0003Vc-6N for 18310@debbugs.gnu.org; Tue, 26 Aug 2014 14:11:08 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1XMLD0-0006qI-4L; Tue, 26 Aug 2014 14:11:06 -0400 From: Glenn Morris To: joaotavora@gmail.com (=?utf-8?B?Sm/Do28gVMOhdm9yYQ==?=) Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> X-Spook: SP4 pink noise Venezuela covert video CipherTAC-2000 X-Ran: Bm%gb#7,CP6xwC`XB?(J[:I/T?NvZwJ>v4dh+3H@"fwuym?1i4#o~`EE`vj,[*(1^ABm4i X-Hue: cyan X-Debbugs-No-Ack: yes X-Attribution: GM Date: Tue, 26 Aug 2014 14:11:05 -0400 In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vo?= =?utf-8?Q?ra=22's?= message of "Mon, 25 Aug 2014 18:23:11 +0100") Message-ID: <9u1ts3ruiu.fsf@fencepost.gnu.org> User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 18310 Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Jo=C3=A3o T=C3=A1vora wrote: > Can anyone verify and install it? Sorry, don't have time to test it right now, but I assume you checked the basic functionality, and it looks like you can install it yourself (in emacs-24 branch)? Would be good to get some automated tests for shr-expand-url. I wonder if it even needs to exist (in trunk); since I doubt shr needs some form of url expansion that url.el hasn't already implemented. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 26 16:38:20 2014 Received: (at 18310) by debbugs.gnu.org; 26 Aug 2014 20:38:20 +0000 Received: from localhost ([127.0.0.1]:52765 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XMNVT-0008Og-Ip for submit@debbugs.gnu.org; Tue, 26 Aug 2014 16:38:19 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:58118) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XMNVP-0008OQ-Gl for 18310@debbugs.gnu.org; Tue, 26 Aug 2014 16:38:16 -0400 Received: by mail-ig0-f172.google.com with SMTP id h15so5156412igd.11 for <18310@debbugs.gnu.org>; Tue, 26 Aug 2014 13:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eWaPFLMTfgZgSCargrnBL4H74UpWe0PT0XjoiVtEOPY=; b=0VqRqai663TOppL2jq6RPZJjd0HXYpL5bRT6c/DS01CxXoFC8lRQpZx0oPChd3+QvK Qd8mR//TCSDmyqnACC1Xapskd3MUMeBc7ced7LXDC+VBRHQVjZsj9q2ltR7LeYsgtIoZ LyxX/i4rhrj9E9hDNAZQfdmbL+K6nWh+r4Ck0gCMgPsbbsXinCN6pgtHYTbFyMVFy+q7 HzIq4VD3Apgto9iXmgsdfA0hEJrOjUFcrdzKXeTVqGuwJF9heGRl1JYPeE94RSSO4Eec ec6SXyrsLV7nsRffNvckpP4nwitrROht9F5xlcVlOMzsLU/WuO7BC1IUdw+TnmhHW6td fJjw== X-Received: by 10.42.199.197 with SMTP id et5mr14107047icb.56.1409085489764; Tue, 26 Aug 2014 13:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.131 with HTTP; Tue, 26 Aug 2014 13:37:48 -0700 (PDT) In-Reply-To: <9u1ts3ruiu.fsf@fencepost.gnu.org> References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <9u1ts3ruiu.fsf@fencepost.gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Tue, 26 Aug 2014 21:37:48 +0100 Message-ID: Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 To: Glenn Morris , Lars Ingebrigtsen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 18310 Cc: Eli Zaretskii , Stefan Monnier , 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Tue, Aug 26, 2014 at 7:11 PM, Glenn Morris wrote: > Jo=C3=A3o T=C3=A1vora wrote: > >> Can anyone verify and install it? > Sorry, don't have time to test it right now, but I assume you checked > the basic functionality, and it looks like you can install it yourself > (in emacs-24 branch)? I use it daily, but mostly on http://www.lispworks.com/documentation/HyperSpec/Front/index.htm which is pretty link-intensive with absolute, relative and anchor links, but I can't say I've tested exhaustively. I could, but I'd have to setup my linux box again, which I don't have acces= s to right now. I could do emacs development in some other environment, or I could keep my sanity :-) Anyway, about next week there should be some time to set it up. > Would be good to get some automated tests for shr-expand-url. I could, if I understood it correctly... > I wonder if it even needs to exist (in trunk); since I doubt > shr needs some form of url expansion that url.el hasn't already > implemented. Precisely, but for some reason Lars used `url-generic-parse-url' in `shr-parse-base', but not quite. .. --=20 Jo=C3=A3o T=C3=A1vora From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 27 01:05:32 2014 Received: (at 18310-done) by debbugs.gnu.org; 27 Aug 2014 05:05:32 +0000 Received: from localhost ([127.0.0.1]:53135 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XMVQK-0007p1-18 for submit@debbugs.gnu.org; Wed, 27 Aug 2014 01:05:32 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:45733 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XMVQG-0007os-Qp for 18310-done@debbugs.gnu.org; Wed, 27 Aug 2014 01:05:29 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1XMVQF-0006Wg-KY; Wed, 27 Aug 2014 01:05:27 -0400 From: Glenn Morris To: 18310-done@debbugs.gnu.org Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <9u1ts3ruiu.fsf@fencepost.gnu.org> X-Spook: Steve Case kibo industrial intelligence Arnett USDOJ X-Ran: 02b$uMG*sPRYquy+7:3Ayxp[H0pr{M.!s>W0Ns,&\O}2.q7_.1]8IL[*ffzaWDGw$;Jm^I X-Hue: yellow X-Debbugs-No-Ack: yes X-Attribution: GM Date: Wed, 27 Aug 2014 01:05:27 -0400 In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Tue, 26 Aug 2014 21:37:48 +0100") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 18310-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Version: 24.3.94 Fine; applied. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 18 13:57:20 2014 Received: (at 18310) by debbugs.gnu.org; 18 Sep 2014 17:57:20 +0000 Received: from localhost ([127.0.0.1]:44728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUfxH-000102-RK for submit@debbugs.gnu.org; Thu, 18 Sep 2014 13:57:20 -0400 Received: from hermes.netfonds.no ([80.91.224.195]:52943) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XUfxF-0000zr-Hf for 18310@debbugs.gnu.org; Thu, 18 Sep 2014 13:57:18 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XUfww-00037j-IU; Thu, 18 Sep 2014 19:56:58 +0200 From: Lars Magne Ingebrigtsen To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Subject: Re: bug#18310: 24.3.93; relative links don't work in eww and Windows 7 References: <83wqa2aqgu.fsf@gnu.org> <83lhqhbyvg.fsf@gnu.org> <9u1ts3ruiu.fsf@fencepost.gnu.org> X-Now-Playing: On's _Your Naked Ghost Comes Back at Night_: "The Lonesome Poetry of Mark Rothko" X-Hashcash: 1:23:140918:rgm@gnu.org::KncpepFe4V9bG6US:0000000Ozr X-Hashcash: 1:23:140918:18310@debbugs.gnu.org::wm8X8owtuiQ3S7o4:0000000000000000000000000000000000000000CdpG X-Hashcash: 1:23:140918:monnier@iro.umontreal.ca::b9n3YH4y5oak71K0:0000000000000000000000000000000000000O5gc X-Hashcash: 1:23:140918:eliz@gnu.org::fHGHjln1t1YyEv+8:00000Sgwe X-Hashcash: 1:23:140918:joaotavora@gmail.com::VydysxGiRjO0bt1R:00000000000000000000000000000000000000000THU9 Date: Thu, 18 Sep 2014 19:56:58 +0200 In-Reply-To: (=?iso-8859-1?Q?=22Jo=E3o_T=E1vora=22's?= message of "Tue, 26 Aug 2014 21:37:48 +0100") Message-ID: User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: 1XUfww-00037j-IU X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1411667819.10216@m9ZMTF5Tc2X+e4N0C6J6Rg X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 18310 Cc: 18310@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Jo=E3o T=E1vora writes: >> I wonder if it even needs to exist (in trunk); since I doubt >> shr needs some form of url expansion that url.el hasn't already >> implemented. > > Precisely, but for some reason Lars used `url-generic-parse-url' > in `shr-parse-base', but not quite. .. I dimly remember writing most of that function before I became aware of the `url-generic-parse-url', which probably explains the inconsistency... --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Fri Jun 20 07:14:43 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 17 Oct 2014 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator