Hi Achim, Carsten, On Mon, Sep 02, 2013 at 10:54:13PM +0200, Carsten Dominik wrote: > > On 2.9.2013, at 18:54, Achim Gratz <strom...@nexgo.de> wrote: > > > Carsten Dominik writes: > >> OK, we now use xdg-open when available on a Linux system. > > > > The availability of xdg-open has nothing to do with whether or not you > > are running Emacs on a Linux system. Indeed, even on a system where it > > is available, it won't do anything useful if you're running from a > > console. While I think it's a good default for someone using a desktop > > that conforms to XDG standards, there should be a check if in fact Emacs > > is running on such a desktop. > > thanks for this input. THis makes it more complicated. Do you know > how I would test this? I do know about the variable window-system, > but that will also return nil when Emacs is running in an xterm, even > though xdg-open would be working in this case.
I think there are four cases of running from a console, 1. a true terminal (the one you get with Ctrl+Alt-Fn, or in runlevel 3) 2. a remote console without X forwarding 3. a remote console with X forwarding 4. a virtual terminal (terminal emulator in a graphical desktop) Now xdg-open will not work for (1-2) (for different reasons), but will work for (3-4). I think it is reasonable to expect if someone chooses "export and open", they are on a graphical desktop and not on (1-2). As for (3), I think even in that case most people will choose to just export, and open in some other way (none of us like X forwarding do we? ;)). As for desktop conformance, Gnome, KDE, XFCE (and by induction LXDE) conforms. I think the key is what happens when it does not: xdg-open fallsback to its own settings. Quoting the Archlinux wiki summary: Inside a desktop environment (e.g. GNOME, KDE, Xfce, etc.), xdg-open simply passes the arguments to that desktop environment's file-opener application (gvfs-open, kde-open, or exo-open, respectively), which means that the associations are left up to the desktop environment. When no desktop environment is detected (for example when one runs a standalone window manager, e.g. Openbox), xdg-open will use its own configuration files. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Given this fallback, I don't think there is much to worry about. If it is there, and the user is on a graphical desktop (3-4), it will work. If it is absent, we still have mailcap. Nothing to lose here. Hope this helps, -- Suvayu Open source is the future. It sets us free.