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

Previous Next

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: Fri, 22 Aug 2014 13:48:51 +0300

> From: joaotavora <at> gmail.com (João Távora)
> Cc: 18310 <at> 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.

Previous Next

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