browse-url and URL handlers (MS-Windows)

browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

Hello,

On MS-Windows I had set browse-url-browser-function to a custom
function which calls 'rundll32 url.dll,FileProtocolHandler ...'  to
open the URL with the dedicated program. I had set that definition
some years ago and I am pretty sure it worked.

With 28.1 it appears that my function is no longer called. It seems to
me it comes from the fact that browse-url uses
browse-url-default-handlers which is defined as:

(("\\`mailto:" . browse-url--mailto)
 ("\\`man:" . browse-url--man)
 (browse-url--non-html-file-url-p . browse-url-emacs))

That means that for a URL which is not identified as HTML browse-url
calls browse-url-emacs. On my system that doesn't work when files are
not ASCII file (PNG, RTF, ...). I can define browse-url-handlers to
set a handler to open those files with an axternal program but I find
it annoying.

When called with a PREFIX browse-url calls
browse-url-secondary-browser-function which calls
browse-url-default-windows-browser. On MS-Windows that function calls
the MS-Windows system's default Web browser

(w32-shell-execute "open" ...)

and everything works as expected.

Why not always call browse-url-default-windows-browser in browse-url?
If I want to open a certain type of file with emacs, I can configure
the system to use emacsclient with that type of file.  IMO things
would be easier.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Stefan Kangas]

Pascal Quesseveur <pquessev@gmail.com> writes:

> Hello,

I recommend sending this to the bug tracker at bug-gnu-emacs@gnu.org
instead, so that it doesn't get lost in the noise.

Thanks.

Re: browse-url and URL handlers (MS-Windows)

[Tassilo Horn]

Pascal Quesseveur <pquessev@gmail.com> writes:

Hi Pascal,

> With 28.1 it appears that my function is no longer called. It seems to
> me it comes from the fact that browse-url uses
> browse-url-default-handlers which is defined as:
>
> (("\\`mailto:" . browse-url--mailto)
>  ("\\`man:" . browse-url--man)
>  (browse-url--non-html-file-url-p . browse-url-emacs))

Yes, your analysis is correct.

> That means that for a URL which is not identified as HTML browse-url
> calls browse-url-emacs.

Not quite: browse-url--non-html-file-url-p is non-nil only for file://
URLs which target a non-HTML file.  In that case, browse-url-emacs will
find the file in the respective mode, e.g., image-mode for images.  That
doesn't seem awfully wrong to me.  It prefers opening files in emacs
rather than external programs, that's for sure.

But if you prefer having them opened by the preferred windows program,
add

  (setq browse-url-handlers
        '((browse-url--non-html-file-url-p
           . browse-url-default-windows-browser)))

to your init file.

If you feel that the default value is totally wrong, please file a bug
report so that this can be discussed.

Bye,
Tassilo

Re: browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

>"TH" == Tassilo Horn <tsdh@gnu.org> writes:

  TH> Not quite: browse-url--non-html-file-url-p is non-nil only for file://
  TH> URLs which target a non-HTML file.  In that case, browse-url-emacs will
  TH> find the file in the respective mode, e.g., image-mode for images.  That
  TH> doesn't seem awfully wrong to me.  It prefers opening files in emacs
  TH> rather than external programs, that's for sure.

Thanks for your explanation. Before going further I will take a closer
look at what is happening in my case with the RTF file.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

Hello,

In fact part of my problems comes from the fact that I was trying to
open an URL pointing to a Windows local file. When the URL is of the
form file://C:/some/file browse-url-emacs does not open the file even
if it is a text file.

From https://en.wikipedia.org/wiki/File_URI_scheme it seems a correct
form for a Windows local file is file:///C:/some/file (3
slashes). When I use this form browse-url-emacs allows to open some
files, but always causes the following message:

File exists, but cannot be read

this although the file is read.

Everything is not working properly. For example in the case of an
image the buffer displays the contents of the file, but not the
image. The messages displayed are:

Type C-c C-c or C-c C-x to view the image as an image or hex.
Cannot display image: ( *mm*-273075 1 8193)
#<buffer kk01.jpg>

I don't konw if this is because of the incorrectly reported read error
when opening the file.  When the file content is displayed in the
buffer I can view the image with C-c C-c.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Augusto Stoffel]

On Tue, 11 Oct 2022 at 12:04, Pascal Quesseveur wrote:

> Hello,
>
> In fact part of my problems comes from the fact that I was trying to
> open an URL pointing to a Windows local file. When the URL is of the
> form file://C:/some/file browse-url-emacs does not open the file even
> if it is a text file.
>
> From https://en.wikipedia.org/wiki/File_URI_scheme it seems a correct
> form for a Windows local file is file:///C:/some/file (3
> slashes). When I use this form browse-url-emacs allows to open some
> files, but always causes the following message:
>
> File exists, but cannot be read
>
> this although the file is read.
>
> Everything is not working properly. For example in the case of an
> image the buffer displays the contents of the file, but not the
> image. The messages displayed are:
>
> Type C-c C-c or C-c C-x to view the image as an image or hex.
> Cannot display image: ( *mm*-273075 1 8193)
> #<buffer kk01.jpg>
>
> I don't konw if this is because of the incorrectly reported read error
> when opening the file.  When the file content is displayed in the
> buffer I can view the image with C-c C-c.

I've come across issues with file URLs in Windows before, and the
problem was that

  (url-filename (url-generic-parse-url "file:///C:/some/file"))

returns "/C:/some/file", with an extra slash at the beginning.

Re: browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

>"AS" == Augusto Stoffel <arstoffel@gmail.com> writes:

  AS> I've come across issues with file URLs in Windows before, and the
  AS> problem was that

  AS>   (url-filename (url-generic-parse-url "file:///C:/some/file"))

  AS> returns "/C:/some/file", with an extra slash at the beginning.

Yes, I have seen. I think it is a bug in url parser but I can't tell
if this is the cause of the error message. As the file is opened in
the end.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Eli Zaretskii]

> From: Augusto Stoffel <arstoffel@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 11 Oct 2022 14:32:21 +0200
> 
> > Type C-c C-c or C-c C-x to view the image as an image or hex.
> > Cannot display image: ( *mm*-273075 1 8193)
> > #<buffer kk01.jpg>
> >
> > I don't konw if this is because of the incorrectly reported read error
> > when opening the file.  When the file content is displayed in the
> > buffer I can view the image with C-c C-c.
> 
> I've come across issues with file URLs in Windows before, and the
> problem was that
> 
>   (url-filename (url-generic-parse-url "file:///C:/some/file"))
> 
> returns "/C:/some/file", with an extra slash at the beginning.

Is the below the right fix?

diff --git a/lisp/url/url-parse.el b/lisp/url/url-parse.el
index 91f47d0..cc3e236 100644
--- a/lisp/url/url-parse.el
+++ b/lisp/url/url-parse.el
@@ -201,6 +201,9 @@ url-generic-parse-url
 	    (when (looking-at "\\?")
 	      (skip-chars-forward "^#"))
 	    (setq file (buffer-substring save-pos (point)))
+            (if (and (eq system-type 'windows-nt)
+                     (string-match-p "/[A-Z]:/" file))
+                (setq file (substring file 1)))
 	    ;; 3.5 Fragment
 	    (when (looking-at "#")
 	      (let ((opoint (point)))

Re: browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:


  EZ> Is the below the right fix?

  EZ> diff --git a/lisp/url/url-parse.el b/lisp/url/url-parse.el
  EZ> index 91f47d0..cc3e236 100644
  EZ> --- a/lisp/url/url-parse.el
  EZ> +++ b/lisp/url/url-parse.el
  EZ> @@ -201,6 +201,9 @@ url-generic-parse-url
  EZ>  	    (when (looking-at "\\?")
  EZ>  	      (skip-chars-forward "^#"))
  EZ>  	    (setq file (buffer-substring save-pos (point)))
  EZ> +            (if (and (eq system-type 'windows-nt)
  EZ> +                     (string-match-p "/[A-Z]:/" file))
  EZ> +                (setq file (substring file 1)))
  EZ>  	    ;; 3.5 Fragment
  EZ>  	    (when (looking-at "#")
  EZ>  	      (let ((opoint (point)))

  It fixes the error in url-generic-parse-url (you have to add "a-z"
in the regexp) but then browse-url-emacs doesn't work anymore. Call to
browse-url-emacs must be interrupted by C-g.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Eli Zaretskii]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 11 Oct 2022 18:59:48 +0200
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
>   EZ> Is the below the right fix?
> 
>   EZ> diff --git a/lisp/url/url-parse.el b/lisp/url/url-parse.el
>   EZ> index 91f47d0..cc3e236 100644
>   EZ> --- a/lisp/url/url-parse.el
>   EZ> +++ b/lisp/url/url-parse.el
>   EZ> @@ -201,6 +201,9 @@ url-generic-parse-url
>   EZ>  	    (when (looking-at "\\?")
>   EZ>  	      (skip-chars-forward "^#"))
>   EZ>  	    (setq file (buffer-substring save-pos (point)))
>   EZ> +            (if (and (eq system-type 'windows-nt)
>   EZ> +                     (string-match-p "/[A-Z]:/" file))
>   EZ> +                (setq file (substring file 1)))
>   EZ>  	    ;; 3.5 Fragment
>   EZ>  	    (when (looking-at "#")
>   EZ>  	      (let ((opoint (point)))
> 
>   It fixes the error in url-generic-parse-url (you have to add "a-z"
> in the regexp) but then browse-url-emacs doesn't work anymore. Call to
> browse-url-emacs must be interrupted by C-g.

Can you show a recipe with browse-url-emacs, starting from "emacs -Q",
which infloops?

Re: browse-url and URL handlers (MS-Windows)

[Lars Ingebrigtsen]

Augusto Stoffel <arstoffel@gmail.com> writes:

> I've come across issues with file URLs in Windows before, and the
> problem was that
>
>   (url-filename (url-generic-parse-url "file:///C:/some/file"))
>
> returns "/C:/some/file", with an extra slash at the beginning.

That's the correct result.  The URL should probably be
"file://C:/some/file" instead.

I.e., everything after the first two slashes is the path on the local
machine.

Re: browse-url and URL handlers (MS-Windows)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Pascal Quesseveur <pquessev@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 11 Oct 2022 19:23:19 +0200
> 
> Augusto Stoffel <arstoffel@gmail.com> writes:
> 
> > I've come across issues with file URLs in Windows before, and the
> > problem was that
> >
> >   (url-filename (url-generic-parse-url "file:///C:/some/file"))
> >
> > returns "/C:/some/file", with an extra slash at the beginning.
> 
> That's the correct result.

It is?  How so?  "/C:/some/file" is an invalid file name on Windows.

> The URL should probably be "file://C:/some/file" instead.

No, on Windows the file:// URLs have 3 slashes.  See

  https://en.wikipedia.org/wiki/File_URI_scheme#Windows

Re: browse-url and URL handlers (MS-Windows)

[Augusto Stoffel]

On Tue, 11 Oct 2022 at 19:23, Lars Ingebrigtsen wrote:

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> I've come across issues with file URLs in Windows before, and the
>> problem was that
>>
>>   (url-filename (url-generic-parse-url "file:///C:/some/file"))
>>
>> returns "/C:/some/file", with an extra slash at the beginning.
>
> That's the correct result.

Perhaps.  But then you would be declaring that it's not url.el's
business to try and fix these Windows filename issues.

> The URL should probably be "file://C:/some/file" instead.

No, for this URL

    (url-host (url-generic-parse-url "file://C:/some/file"))
    ;;=> c

and that's correct.

> I.e., everything after the first two slashes is the path on the local
> machine.

According to Wikipedia the original URL (with three slashes) is correct.

Re: browse-url and URL handlers (MS-Windows)

[Augusto Stoffel]

On Tue, 11 Oct 2022 at 19:36, Eli Zaretskii wrote:

> Is the below the right fix?
>
> diff --git a/lisp/url/url-parse.el b/lisp/url/url-parse.el
> index 91f47d0..cc3e236 100644
> --- a/lisp/url/url-parse.el
> +++ b/lisp/url/url-parse.el
> @@ -201,6 +201,9 @@ url-generic-parse-url
>  	    (when (looking-at "\\?")
>  	      (skip-chars-forward "^#"))
>  	    (setq file (buffer-substring save-pos (point)))
> +            (if (and (eq system-type 'windows-nt)
> +                     (string-match-p "/[A-Z]:/" file))
> +                (setq file (substring file 1)))
>  	    ;; 3.5 Fragment
>  	    (when (looking-at "#")
>  	      (let ((opoint (point)))

I would additionally check that the URL in question is a file:// URL.
But I'm not sure these generic URL functions are the right place to “fix”
this particular Windows weirdness.

Re: browse-url and URL handlers (MS-Windows)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The URL should probably be "file://C:/some/file" instead.
>
> No, on Windows the file:// URLs have 3 slashes.  See
>
>   https://en.wikipedia.org/wiki/File_URI_scheme#Windows

Ah, right.  In any case, the result from url-parse is correct, as far as
I can see -- otherwise you won't be getting back the original URL with 

(url-recreate-url (url-generic-parse-url "file:///C:/some/file"))
=> "file:///C:/some/file"

which should (usually) be the case.

Re: browse-url and URL handlers (MS-Windows)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: arstoffel@gmail.com,  pquessev@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 11 Oct 2022 20:04:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The URL should probably be "file://C:/some/file" instead.
> >
> > No, on Windows the file:// URLs have 3 slashes.  See
> >
> >   https://en.wikipedia.org/wiki/File_URI_scheme#Windows
> 
> Ah, right.  In any case, the result from url-parse is correct, as far as
> I can see -- otherwise you won't be getting back the original URL with 
> 
> (url-recreate-url (url-generic-parse-url "file:///C:/some/file"))
> => "file:///C:/some/file"
> 
> which should (usually) be the case.

It could mean another bug, in url-recreate-url.

Re: browse-url and URL handlers (MS-Windows)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It could mean another bug, in url-recreate-url.

I doubt there are many bugs in a basic URL parsing library like this,
and certainly not anything as fundamental as this.

I didn't follow the thread -- what is this trying to fix?

Re: browse-url and URL handlers (MS-Windows)

[Stefan Monnier]

> +            (if (and (eq system-type 'windows-nt)
> +                     (string-match-p "/[A-Z]:/" file))
> +                (setq file (substring file 1)))

I haven't looked at the surrounding code, so I have no idea if it's the
right place to do that, but the above regexp lacks a \` anchor, I think.


        Stefan

Re: browse-url and URL handlers (MS-Windows)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> The URL should probably be "file://C:/some/file" instead.
>>
>> No, on Windows the file:// URLs have 3 slashes.  See
>>
>>   https://en.wikipedia.org/wiki/File_URI_scheme#Windows
>
> Ah, right.  In any case, the result from url-parse is correct, as far as
> I can see -- otherwise you won't be getting back the original URL with 

I was right the first time around:

https://datatracker.ietf.org/doc/html/rfc8089

Everything after the first two slashes is the local-part, so the
local-part of "file:///C:/some/file" is "/C:/some/file", which the URL
library does correctly.

But it's up to the local host to interpret the local part, and
apparently the conventions on Windows is to do further processing on the
"/C:/some/file" part of the URL to end up at "C:/some/file", but that
has to be done on a much higher level.

Re: browse-url and URL handlers (MS-Windows)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: arstoffel@gmail.com,  pquessev@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 11 Oct 2022 20:52:54 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> The URL should probably be "file://C:/some/file" instead.
> >>
> >> No, on Windows the file:// URLs have 3 slashes.  See
> >>
> >>   https://en.wikipedia.org/wiki/File_URI_scheme#Windows
> >
> > Ah, right.  In any case, the result from url-parse is correct, as far as
> > I can see -- otherwise you won't be getting back the original URL with 
> 
> I was right the first time around:

Then I guess you get to solve this bug.

Re: browse-url and URL handlers (MS-Windows)

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: arstoffel@gmail.com,  pquessev@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 11 Oct 2022 20:24:46 +0200
> 
> I didn't follow the thread -- what is this trying to fix?

This:

  https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00218.html
  https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00406.html
  https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00930.html

Re: browse-url and URL handlers (MS-Windows)

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I didn't follow the thread -- what is this trying to fix?
>
> This:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00218.html
>   https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00406.html
>   https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg00930.html

Looks like it should be fixed in browse-url-emacs?

But a proper bug report with a complete recipe to reproduce the problem
would be nice.

Re: browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

>"LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

  LI> But a proper bug report with a complete recipe to reproduce the
  LI> problem would be nice.

I have reported bug#58464 which concerns only browse-url-emacs not
opening local URLs on Windows when there are only 2 slashes after
file:, and displaying an error message when there are 3 slashes.

I tend to think there is also a bug in url parsing for local windows
paths, but I am not sure if the 2 are related, and even if it's really
a bug. So I didn't report anything about this one.


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Pascal Quesseveur]

>"EZ" == Eli Zaretskii <eliz@gnu.org> writes:

  EZ> Can you show a recipe with browse-url-emacs, starting from
  EZ> "emacs -Q", which infloops?

1. emacs -Q

2. I checked original function url-generic-parse-url:

(require 'url-handlers)
(url-filename (url-generic-parse-url "file:///C:/Windows/win.ini"))

url-handlers
"/C:/Windows/win.ini"

3. I applied the patch and reload url-generic-parse-url:

url-generic-parse-url
"C:/Windows/win.ini"

4. I checked browse-url-emacs:

(browse-url-emacs "file://C:/Windows/win.ini")
(browse-url-emacs "file:///C:/Windows/win.ini")

Emacs hangs each time:

Quit [2 times]

5. I reload original url-generic-parse-url function and checked
again browse-url-emacs: first call hangs again, but second one
doesn't:

url-generic-parse-url
Quit
File exists, but cannot be read
#<buffer win.ini<3>>


HTH


-- 
Pascal Quesseveur
pquessev@gmail.com

Re: browse-url and URL handlers (MS-Windows)

[Augusto Stoffel]

On Tue, 11 Oct 2022 at 20:52, Lars Ingebrigtsen wrote:

> But it's up to the local host to interpret the local part, and
> apparently the conventions on Windows is to do further processing on the
> "/C:/some/file" part of the URL to end up at "C:/some/file", but that
> has to be done on a much higher level.

This sounds reasonable.  I just wanted to note that browse-url-emacs
would be third place I know of that need this kind of processing (the
other two being eglot and comint-mime).  So I guess a helper function is
in order here.