Hi Eli, 
I didn’t send an email saying that I would do it last weekend, I thought "nah surely this week I get to it". And here we are :(

But yes I will! :) As soon as I get a chance. 

On Sat, Mar 29, 2025, at 7:16 AM, Eli Zaretskii wrote:
Ping!  Sebastián, would you like to submit an updated patch which
addresses my comments?

> Cc: 76982@debbugs.gnu.orgmorgan@ice9.digital
> Date: Thu, 13 Mar 2025 10:20:41 +0200
> From: Eli Zaretskii <eliz@gnu.org>

> > Cc: 76982@debbugs.gnu.org
> > From: Sebastián Monía
> >  <sebastian@sebasmonia.com>
> > Date: Wed, 12 Mar 2025 15:23:08 -0400
> > 
> > Morgan Willcock <morgan@ice9.digital> writes:
> > 
> > >   (url-filename (url-generic-parse-url "file:///c:/windows"))
> > >   => "/c:/windows"
> > >
> > >   (url-filename (url-generic-parse-url "c:/windows"))
> > >   => "/windows"
> > >
> > > This is relevant in functions such as
> > > mml-expand-html-into-multipart-related, where there is a check that the
> > > file exists:
> > >
> > >   (when (and (null (url-type parsed))
> > >              (not (zerop (length (url-filename parsed))))
> > >              (file-exists-p (url-filename parsed)))
> > >     ...)
> > >
> > > An example of a real world problem is being unable to reliably send HTML
> > > mail when using Windows:
> > >
> > > https://github.com/jeremy-compostella/org-msg/issues/122
> > 
> > Attached a potential patch.

> Thanks.

> > >From 25c0cbeb1523e3fed3d3409465b6dcc99c967a38 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Sebasti=C3=A1n=20Mon=C3=ADa?=
> >  <sebastian.monia@sebasmonia.com>
> > Date: Wed, 12 Mar 2025 15:16:19 -0400
> > Subject: [PATCH] url-parse.el: Parsing exceptions for Windows paths
> >  (bug#76982)

> Please add a ChangeLog-style list of functions that are modified and a
> short description of each modification.

> > 
> > ---
> >  lisp/url/url-parse.el | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lisp/url/url-parse.el b/lisp/url/url-parse.el
> > index 4c65721b83d..1dff66c6228 100644
> > --- a/lisp/url/url-parse.el
> > +++ b/lisp/url/url-parse.el
> > @@ -83,7 +83,12 @@ url-recreate-url
> >  ;; port is empty or if its value would be the same as that of
> >  ;; the scheme's default."
> >  (port (url-port-if-non-default urlobj))
> > - (file (url-filename urlobj))
> > +         ;; For Windows/DOS-like paths, `url-generic-parse-url' strips
> > +         ;; the leading /, so we need to add it back (bug#76982)
> > + (file (if (and (string= "file" type)
> > +                        (string-match "^[A-Za-z]:[/\\]" (url-filename urlobj)))
> > +                   (concat "/" (url-filename urlobj))
> > +                 (url-filename urlobj)))
> >  (frag (url-target urlobj)))
> >      (concat (if type (concat type ":"))
> >      (if (url-fullness urlobj) "//")

> OK.

> > @@ -210,6 +215,13 @@ url-generic-parse-url
> >  
> >            (if (and host (string-match "%[0-9][0-9]" host))
> >                (setq host (url-unhex-string host)))
> > +
> > +          ;; For file:// URIs, if the path "looks like" Windows/DOS, it
> > +          ;; makes sense to strip the leading slash (bug#76982)
> > +          (when (and (string= "file" scheme)
> > +                     (string-match "^/[A-Za-z]:[/\\]" file))
> > +            (setq file (substring file 1)))
> > +
> >            (url-parse-make-urlobj scheme user pass host port file
> >  fragment nil full))))))

> Isn't it cleaner to go one more character forward here:

>           ;; 3.2. Authority
>           (when (looking-at "//")
>             (setq full t)
>             (forward-char 2)  <<<<<<<<<<<<<<<<<<<<
>             (setq save-pos (point))
>             (skip-chars-forward "^/?#")

> if the conditions for Windows-style absolute file name are fulfilled?

> Also, could we please have some simple tests for this?