GNU bug report logs - #18310
24.3.93; relative links don't work in eww and Windows 7

Previous Next

Package: emacs;

Reported by: joaotavora <at> gmail.com (João Távora)

Date: Thu, 21 Aug 2014 10:35:01 UTC

Severity: normal

Found in version 24.3.93

Fixed in version 24.3.94

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: joaotavora <at> gmail.com (João Távora)
Cc: 18310 <at> debbugs.gnu.org
Subject: bug#18310: 24.3.93; relative links don't work in eww and Windows 7
Date: Thu, 21 Aug 2014 19:17:55 +0300
> From: joaotavora <at> gmail.com (João Távora)
> Cc: 18310 <at> 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.




This bug report was last modified 10 years and 249 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.