bug#67736: 30.0.50; emacsclient.desktop fails with quoting-related error

[Ulrich Mueller]

>>>>> On Mon, 18 Dec 2023, Mekeor Melire wrote:

> So, when testing, do not use graphical file-managers. Instead, use the
> xdg-open executable from xdg-utils package in a shell. Edit the file at
> ~/.config/mimeapps.list (or similar) yourself rather than letting some
> GUI do it. And check the content of your emacsclient.desktop since it
> might be altered by your distro.

> When sharing results, please also share which version your xdg-utils
> package has, and which patches had been applied on its source code
> before it was built.

Sure. My /usr/share/applications/emacsclient.desktop is identical to the
one from Emacs master (as of today). Also, it is what is used for plain
text files:

   $ xdg-mime query default text/plain
   emacsclient.desktop

I've now also tested with xdg-utils-1.2.0-beta1 and with 1.1.3, manually
installed from the tarball available at:
https://gitlab.freedesktop.org/xdg/xdg-utils/-/tags/v1.1.3

I cannot reproduce the problem with either of them:

   $ xdg-open --version
   xdg-open 1.1.3
   $ echo hello >foo.txt && xdg-open foo.txt
   Waiting for Emacs...

This correctly visits the file in my running Emacs.

However, I also see that xdg-open delegates handling of the file to
exo-open from XFCE (and similar for GNOME, KDE, etc.). So maybe xdg-open
sometimes doesn't parse the desktop file by itself? Which would explain
why I don't see the problem.

> [...]

> The problem is that xdg-utils does not adhere to its own specification.
> It seems like some distros patched it to be better at that though.

> I think a prior version of emacsclient-mail.desktop is bad reference for
> comparison. Compared to other .desktop-files in the FOSS-world,
> emacsclient.desktop has a very complicated, maybe the most complicated
> Exec-entry. I can't prove this by representative statistics but only
> refer to my own experience, and quote the reaction of the person, who by
> far made the most commits on xdg-utils recently, when seeing the
> emacsclient.desktop-files Exec-entry: "That is … one hell of an exec
> line." [3]

The line conforms to the spec, so xdg-open should be able to handle it.
Then again, the line is "one hell" only because (IMHO) their own
specification sucks and requires complicated quoting plus multiple
telnet-song-esque backslash-escaping.

(Also I'm a little shocked by the reaction of the upstream person. It's
their specification and their reference implementation, so why don't
they have unit tests for all intricacies of the Exec line?)

> Honestly, I don't know how to handle this tricky situation:
> freedesktop.org has specification for Exec entries in .desktop-files.
> xdg-utils itself does implement this specification correctly.

Is a "not" missing there? Otherwise I don't understand the sentence.

> Fixing the bug will probably take its developers a long time because
> they want to rewrite it (in Python). Meanwhile, xdg-utils is less/not
> buggy for most users because their distro patches it.

*sigh* Standards exist for a reason, namely that developers can program
against them, instead of second-guessing other implementations.

I think we have established that the bug is in xdg-utils, so that's
where it should be ultimately fixed. Not sure if it's worth having a
short-term workaround using a wrapper script.