bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]