[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open'
Florian v. Savigny
Re: bug#18986: Design bug in browse-url.el: browse-url-can-use-xdg-open's logic uses overly strict assumption
Sat, 15 Nov 2014 13:31:39 +0100
> From: Stefan Monnier <address@hidden>
> 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
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
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:
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
Florian von Savigny