Re: url-generic-parse-url with Windows file paths

[Eli Zaretskii]

> From: Sebastián Monía <sebastian@sebasmonia.com>
> Cc: morgan@ice9.digital,  emacs-devel@gnu.org
> Date: Wed, 12 Mar 2025 10:13:16 -0400
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Sebastián Monía <sebastian@sebasmonia.com>
> >> I think it should be up to the consumers of url-parse to know how to
> >> interpret the filename portion. Going back to the original code, this
> >> statement:
> >>     (file-exists-p (url-filename parsed))
> >> 
> >> Should strip the leading / when the path is known to be for a Windows
> >> filesystem.
> >
> > Bu that gets us back to the problem with deciding whether the file
> > name is from Windows or from a Posix system.  And file-exists-p is too
> > ubiquitous to change what it does now, anyway.
> 
> I think I explained myself better in the next email, but I don't suggest
> changing file-exists-p. Whoever parses a URL would know better if it's
> meant to be a Windows path, and should drop the leading /, before
> calling file-exists-p.

That's possible, but it's better to fix url-parse to DTRT in the first
place.

> > So if url-generic-parse-url cannot solve this problem (and I'm not
> > sure it's so, since the chances of "file:///c:/foo" to be a Posix file
> > name are extremely slim at best), we need to solve it "by hand" in
> > mml-expand-html-into-multipart-related, for example like this:
> >
> >   (let ((file (url-filename (url-filename parsed))))
> >     (or (file-exists-p file)
> >         (and (memq system-type '(windows-nt ms-dos))
> >          (string-match-p "\\`[/\\][a-z]:[/\\]" file)
> >          (file-exists-p (substring file 1)))))
> 
> This was my suggestion, whoever uses the output of url-filename is in a
> better position to know if it's a Windows or POSIX path.
>        
> I am curious about your next email and your comment in parenthesis
> above. Do you think we should change url-filename to strip the leading /
> when we see the pattern "\{a single letter}:"?

I think it is better to assume that "file:///c:" happens on Windows
than to assume that "/c:" happens on Windows.  IOW, I think it is
better to fix this in url-generic-parse-url that in url-filename,
since the latter is basically just an accessor.