[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18310: 24.3.93; relative links don't work in eww and Windows 7
From: |
Eli Zaretskii |
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@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.
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, João Távora, 2014/08/21
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Eli Zaretskii, 2014/08/21
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, João Távora, 2014/08/21
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Eli Zaretskii, 2014/08/21
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, João Távora, 2014/08/21
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Eli Zaretskii, 2014/08/21
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, João Távora, 2014/08/22
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7,
Eli Zaretskii <=
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Stefan Monnier, 2014/08/22
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Eli Zaretskii, 2014/08/22
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, João Távora, 2014/08/25
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Glenn Morris, 2014/08/26
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, João Távora, 2014/08/26
- bug#18310: 24.3.93; relative links don't work in eww and Windows 7, Glenn Morris, 2014/08/27