Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Florian v. Savigny]

Dear maintainers/authors,

browse-url-can-use-xdg-open returns t only if emacs is running under one of the desktop environments, i.e. Gnome, KDE, Xfce4 or LXDE.

I do not know the deeper reasons for this, but from experience, I can confirm that this running under a desktop environment may be sufficient, but is not necessary: My emacs is running under fvwm, and xdg-open works fine. (You have to know how to configure it, but that is no dark magic either; I do it via ~/.local/share/applications/mimeapps.list.)

My guess is that it would be sufficient to check for the existence of the xdg-open binary. The condition of one of the desktop environments being run is somewhat annoying, because when not fulfilled, it causes browse-url-default-browser, which is often employed to open a URL, to default to mozilla (or whatever follows in its hardcoded list), which may not be exactly what you want. Effectively, it makes it impossible to specify your favourite browser without some kludgy hack.

I have included some of the information produced by M-x report-emacs-bug, but since I am fairly certain that most of it is irrelevant, I have left it out:


In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-21 on bitzer.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.11601000
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong --param=ssp-buffer-size=4'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: de_DE.ISO-8859-1
  locale-coding-system: iso-latin-1-unix


Best regards,

Florian v. Savigny

bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Jan D.]

Hello.

It used to be that xdg-open just called the desktop version, i.e. gnome-open, kde-open and so on.  It is not sufficient that xdg-open exists for the most part.  We can't cater for every window manager out there, we have to go by the majority.  If you can make xdg-open work, then making Emacs use it should be easy.

	Jan D.

> 7 nov 2014 kl. 12:04 skrev Florian v. Savigny <florian@fsavigny.de>:
> 
> 
> 
> Dear maintainers/authors,
> 
> browse-url-can-use-xdg-open returns t only if emacs is running under one of the desktop environments, i.e. Gnome, KDE, Xfce4 or LXDE.
> 
> I do not know the deeper reasons for this, but from experience, I can confirm that this running under a desktop environment may be sufficient, but is not necessary: My emacs is running under fvwm, and xdg-open works fine. (You have to know how to configure it, but that is no dark magic either; I do it via ~/.local/share/applications/mimeapps.list.)
> 
> My guess is that it would be sufficient to check for the existence of the xdg-open binary. The condition of one of the desktop environments being run is somewhat annoying, because when not fulfilled, it causes browse-url-default-browser, which is often employed to open a URL, to default to mozilla (or whatever follows in its hardcoded list), which may not be exactly what you want. Effectively, it makes it impossible to specify your favourite browser without some kludgy hack.
> 
> I have included some of the information produced by M-x report-emacs-bug, but since I am fairly certain that most of it is irrelevant, I have left it out:
> 
> 
> In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
> of 2014-10-21 on bitzer.hoetzel.info
> Windowing system distributor `The X.Org Foundation', version 11.0.11601000
> Configured using:
> `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
> --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
> 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
> -fstack-protector-strong --param=ssp-buffer-size=4'
> CPPFLAGS=-D_FORTIFY_SOURCE=2
> LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
> 
> Important settings:
>  value of $LANG: de_DE.ISO-8859-1
>  locale-coding-system: iso-latin-1-unix
> 
> 
> Best regards,
> 
> Florian v. Savigny
> 
> 
> 
> 

Re: bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Jan D.]

Hello.

It used to be that xdg-open just called the desktop version, i.e. gnome-open, kde-open and so on.  It is not sufficient that xdg-open exists for the most part.  We can't cater for every window manager out there, we have to go by the majority.  If you can make xdg-open work, then making Emacs use it should be easy.

	Jan D.

> 7 nov 2014 kl. 12:04 skrev Florian v. Savigny <florian@fsavigny.de>:
> 
> 
> 
> Dear maintainers/authors,
> 
> browse-url-can-use-xdg-open returns t only if emacs is running under one of the desktop environments, i.e. Gnome, KDE, Xfce4 or LXDE.
> 
> I do not know the deeper reasons for this, but from experience, I can confirm that this running under a desktop environment may be sufficient, but is not necessary: My emacs is running under fvwm, and xdg-open works fine. (You have to know how to configure it, but that is no dark magic either; I do it via ~/.local/share/applications/mimeapps.list.)
> 
> My guess is that it would be sufficient to check for the existence of the xdg-open binary. The condition of one of the desktop environments being run is somewhat annoying, because when not fulfilled, it causes browse-url-default-browser, which is often employed to open a URL, to default to mozilla (or whatever follows in its hardcoded list), which may not be exactly what you want. Effectively, it makes it impossible to specify your favourite browser without some kludgy hack.
> 
> I have included some of the information produced by M-x report-emacs-bug, but since I am fairly certain that most of it is irrelevant, I have left it out:
> 
> 
> In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
> of 2014-10-21 on bitzer.hoetzel.info
> Windowing system distributor `The X.Org Foundation', version 11.0.11601000
> Configured using:
> `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
> --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
> 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
> -fstack-protector-strong --param=ssp-buffer-size=4'
> CPPFLAGS=-D_FORTIFY_SOURCE=2
> LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'
> 
> Important settings:
>  value of $LANG: de_DE.ISO-8859-1
>  locale-coding-system: iso-latin-1-unix
> 
> 
> Best regards,
> 
> Florian v. Savigny
> 
> 
> 
> 

bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Stefan Monnier]

> It used to be that xdg-open just called the desktop version,
> i.e. gnome-open, kde-open and so on.  It is not sufficient that xdg-open
> exists for the most part.  We can't cater for every window manager out
> there, we have to go by the majority.  If you can make xdg-open work, then
> making Emacs use it should be easy.

The problem was specifically that just having xdg-open installed doesn't
guarantee that the user has configured it.
The code currently approximate "is it configured" by checking the
desktop environment in use.  It's clearly a gross hack (or a crude
approximation), so if you know a better way, we'd like to hear it.


        Stefan

bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Florian v. Savigny]

  > From: Stefan Monnier <monnier@iro.umontreal.ca>
  > Date: Sat, 08 Nov 2014 13:05:54 -0500
  > 
  > The problem was specifically that just having xdg-open installed
  > doesn't guarantee that the user has configured it.  The code
  > currently approximates "is it configured" by checking the desktop
  > environment in use.  It's clearly a gross hack (or a crude
  > approximation), so if you know a better way, we'd like to hear it.


Thank you very much for your feedback!

It would seem to me that checking if

   xdg-mime query default text/html

or, in a more general way, perhaps

   xdg-mime query default `xdg-mime query filetype URL/FILE`

returns SOMETHING should be sufficient.

I am absolutely NOT sure, I have to admit, because I have found the
documentation for the xdg system not very accessible if you are
interested in manual configuration, and lack the time to study it
hard.

I have found that what the above command returns is not necessarily
what xdg-open will actually run (i.e. it does not seem to reflect user
reconfiguration - which is probably why the query is called
"default"), but it would seem to me that if it returns SOMETHING,
there is a guarantee that there is a default, which in turn guarantees
that xdg-open will start SOMETHING.

This line of thought assumes that /usr/share/applications/*.desktop
files for any given application will ONLY be there if the application
itself is also installed, i.e. that they both come with the same
package. I think that this is the case for any distribution I have
used so far.

Even if this assumption is unsafe, I think one could check if the
return value of xdg-open is 3 or 4, which could then lead to a message
such as "Please configure your xdg system properly; see man xdg-mime
or your desktop environment's configuration tool" and/or to some
fallback action (which browse-url is already capable of). Of course,
this last measure could not be implemented within the
browse-url-can-use-xdg-open function.

An alternative approach (which would however not be mutually exclusive
with the above) might be to make the hardcoded browser list in
browse-url-default-browser customisable, which currently forces an
order of preference on the user as follows:


browse-url-gnome-moz-program
browse-url-mozilla-program
browse-url-firefox-program
browse-url-chromium-program
browse-url-galeon-program
browse-url-kde-program
browse-url-netscape-program
browse-url-mosaic-program
browse-url-xterm-program


The reason why I am somehow uncomfortable with browse-url's logic of
determining a browser to start is that I find it effectively (if most
probably not intentionally) patronising, and this is, in my view,
unusual for Emacs - out of character, as it were.

I would like to apologise if my suggestions are not sufficiently
substantial.

Best regards,

-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld

Re: bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Florian v. Savigny]

  > From: Stefan Monnier <monnier@iro.umontreal.ca>
  > Date: Sat, 08 Nov 2014 13:05:54 -0500
  > 
  > The problem was specifically that just having xdg-open installed
  > doesn't guarantee that the user has configured it.  The code
  > currently approximates "is it configured" by checking the desktop
  > environment in use.  It's clearly a gross hack (or a crude
  > approximation), so if you know a better way, we'd like to hear it.


Thank you very much for your feedback!

It would seem to me that checking if

   xdg-mime query default text/html

or, in a more general way, perhaps

   xdg-mime query default `xdg-mime query filetype URL/FILE`

returns SOMETHING should be sufficient.

I am absolutely NOT sure, I have to admit, because I have found the
documentation for the xdg system not very accessible if you are
interested in manual configuration, and lack the time to study it
hard.

I have found that what the above command returns is not necessarily
what xdg-open will actually run (i.e. it does not seem to reflect user
reconfiguration - which is probably why the query is called
"default"), but it would seem to me that if it returns SOMETHING,
there is a guarantee that there is a default, which in turn guarantees
that xdg-open will start SOMETHING.

This line of thought assumes that /usr/share/applications/*.desktop
files for any given application will ONLY be there if the application
itself is also installed, i.e. that they both come with the same
package. I think that this is the case for any distribution I have
used so far.

Even if this assumption is unsafe, I think one could check if the
return value of xdg-open is 3 or 4, which could then lead to a message
such as "Please configure your xdg system properly; see man xdg-mime
or your desktop environment's configuration tool" and/or to some
fallback action (which browse-url is already capable of). Of course,
this last measure could not be implemented within the
browse-url-can-use-xdg-open function.

An alternative approach (which would however not be mutually exclusive
with the above) might be to make the hardcoded browser list in
browse-url-default-browser customisable, which currently forces an
order of preference on the user as follows:


browse-url-gnome-moz-program
browse-url-mozilla-program
browse-url-firefox-program
browse-url-chromium-program
browse-url-galeon-program
browse-url-kde-program
browse-url-netscape-program
browse-url-mosaic-program
browse-url-xterm-program


The reason why I am somehow uncomfortable with browse-url's logic of
determining a browser to start is that I find it effectively (if most
probably not intentionally) patronising, and this is, in my view,
unusual for Emacs - out of character, as it were.

I would like to apologise if my suggestions are not sufficiently
substantial.

Best regards,

-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]


Sorry for digging out this old issue, but it seemed that Florian's
suggestion (which was pretty good in my opinion) was never answered.

I've been battling with browse-url for longer than necessary, it seems
to me that there are just too many rough edges around xdg-open,
xdg-mime, ~/.config/mimeapps.list, `mailcap-mime-extensions'...

Having `browse-url-can-use-xdg-open' _and_ a customizable list of
default browser in `browse-url-default-browser' would help tremendously.

I'd like to add one more feature which could relieve non-DE users even further:

	(defun browse-url-default-browser (url &rest args)
	...
	  (apply
	   (cond
	   ...
	+   ((getenv "BROWSER") (executable-find (getenv "BROWSER")))
	    ((memq system-type '(windows-nt ms-dos cygwin))
	     'browse-url-default-windows-browser)

The "BROWSER" environment variable is relativement common and if it is
set, it most probably means that the users did that themselves.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Eli Zaretskii]

> From: Pierre Neidhardt <ambrevar@gmail.com>
> Date: Mon, 12 Feb 2018 17:23:26 +0100
> 
> Sorry for digging out this old issue, but it seemed that Florian's
> suggestion (which was pretty good in my opinion) was never answered.

What version of Emacs are you looking at?

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 64 bytes --]


25.3, can't follow master at the moment.  Is it already fixed?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Eli Zaretskii]

> From: Pierre Neidhardt <ambrevar@gmail.com>
> Cc: 18986@debbugs.gnu.org
> Date: Mon, 12 Feb 2018 18:51:43 +0100
> 
> 25.3, can't follow master at the moment.

Can you look at the latest pretest of 26.1?  It's on alpha.gnu.org.

> Is it already fixed?

The code is definitely different from what you show.  It's supposed to
be fixed, but I don't know enough about that stuff to say, so it would
be good if you could take a look at the current code.

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 100 bytes --]


> Can you look at the latest pretest of 26.1?  It's on alpha.gnu.org.

I will as soon as possible.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Noam Postavsky]

tag 18986 - notabug wontfix
fixed 18986 26.1
unarchive 25778
merge 18986 25778
quit

Pierre Neidhardt <ambrevar@gmail.com> writes:

>> Can you look at the latest pretest of 26.1?  It's on alpha.gnu.org.
>
> I will as soon as possible.

From what I can tell, the Emacs 26 code is pretty close to what Florian
suggested, you can see it also in Bug#25778 which I've merged.

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]


OK, I'm running Emacs 26 now, and it the xdg-open is indeed solved as per #25778.

Still one rough edge left:  if xdg-open is missing but BROWSER is set,
Emacs will not run the browser configured by the user but the first one
it found in the list.

I think the patch I suggested above would be good enough, or maybe even better:

	(defun browse-url-default-browser (url &rest args)
	...
	  (apply
	   (cond
	   ...
	+   ((and (getenv "BROWSER") (executable-find (getenv "BROWSER")))
  +    (executable-find (getenv "BROWSER")))
	    ((memq system-type '(windows-nt ms-dos cygwin))
	     'browse-url-default-windows-browser)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#18986: #18986 Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]


Actually the design issue is a bit deeper than that: As of now (even
with my suggested change) there is no proper way of retrieving the
browser name.

This can be problematic especially when it comes to managing processes
and frames (e.g. with EXWM).

So I suggest the following refactoring:

- Remove `browse-url-generic'.

- `browse-url-browser-function' should return a browser name (the function
might need a new name).

- `browse-url-default-browser' should obey the change and return a browser
name, with the first check being on `browse-url-generic-program`, second
check on the environment variable, third check on xdg-open, and the rest
as usual.

Everything gets simple, both the code and the user configuration, plus
it's more flexible.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]