bug#70914: 29.3; Crashes often on Windows

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: simendsjo@gmail.com, ssbssa@yahoo.de, corwin@bru.st, 70914@debbugs.gnu.org
> Date: Thu, 23 May 2024 11:51:51 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> No. Org mode strips file: from the filename and only passes the links
> >> path (link is defined as type:path)
> >
> > Where does that happen?  If Org does that on Windows, that's a bug:
> > file:// URIs on Windows should be interpreted differently.  See
> >
> >   https://en.wikipedia.org/wiki/File_URI_scheme
> 
> There is no bug here. Org mode fontifies links defined by Org mode
> syntax: type:path where type can be file,eww,help,etc and path is
> text after type:.
> 
> So, when a package/user is supplying custom :activate-func, Org calls it
> according to the convention:
> 
> `:activate-func'
> 
>   Function to run at the end of Font Lock activation.  It must
>   accept four arguments:
>   - the buffer position at the start of the link,
>   - the buffer position at its end,
>   - the path, as a string,
>   - a boolean, non-nil when the link has brackets.
> 
> Here, "path" is *Org link path, according to Org mode syntax*.
> So, if there is a custom function that should fontify file: links, it
> knows that PATH is everything that following file:. In the discussed
> case Org mode's file:// link is structured as
> 
> :type: "file"
> :type-explicit-p: t
> :path: "//"
> :format: plain
> :raw-link: "file://"
> :application: nil
> :search-option: nil
> 
> The :activate-func is passed the :path part, and it should know that it
> is used for "file" :type. So, it has all the information necessary to
> reconstruct the raw link. It can do anything it wants to with that
> information.

My point is that if the URI is "file://", the corresponding :path on
Windows is not "//".

> IMHO, the bug is in file-exists-p:

I don't think so.  "//" is an invalid file name on Windows, so the
only requirement from file-exists-p in that case is not to crash.
Which it does, after the recent fix.

So now the above case is not fatal as it was before, but it is still
incorrect, and I hope will be fixed.