2023-12-17 16:35 ulm@gentoo.org:

> On Sun, 17 Dec 2023, Peter Oliver wrote:
>
> > I don’t experience it on Fedora, but I notice that the Fedora version
> > of xdg-utils carries an awful lot of patches
> > (https://src.fedoraproject.org/rpms/xdg-utils/tree/f38).
>
> I cannot reproduce the problem on Gentoo either. The Gentoo package uses
> a snapshot of xdg-utils from 2021 because the 1.1.3 release is very old:
> https://gitlab.freedesktop.org/xdg/xdg-utils/-/commits/1a58bc28f6844898532daf9ee1bf6da7764955a9/

Yes, many distros patch xdg-utils. On #emacs-IRC-channel I was even told
that file-explorers like GNOME's Nautilus and LXDE's pcmanfm tinker with
.desktop-files, e.g. they might ship their own emacsclient.desktop file.

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.

Personally, I use xdg-utils 1.1.3, the latest stable release, installed
with Guix, which only includes some minor code-changes that make it find
executables on Guix System. [1] My emacsclient.desktop is from Emacs
master branch without changes.

Gentoo does not only build xdg-utils from an unreleased commit, but also
it applies some additional patches [2], one of which seems to alter the
handling of Exec-entries.

> (Also, xdg-utils-1.2.0 seems to be on its way; upstream has released a
> 1.2.0-beta1 version.)

Thanks for point this out. In reaction to your e-mail, I tried out the
1.2.0-beta1 version (using Guix and the package declaration that I
attached to this e-mail). Unfortunately, I'm still running in the same
error as before:

    [: -c: line 1: unexpected EOF while looking for matching `"'
    [: -c: line 2: syntax error: unexpected end of file

> > I agree that the quoting is too complex, and would be better
> > eliminated.
>
> I've double checked: The quoting in the desktop file is definitely
> according to the specification. IMHO it isn't particularly complex in
> emacsclient.desktop, at least compared to what we previously had in
> emacsclient-mail.desktop.

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]

> > A wrapper script could achieve the same functionality.
>
> All previous committers have avoided a wrapper script, because inlining
> the shell command gets the work done.

Which work does it get done though? The work is the "pass --create-frame
when there are no file-arguments" logic. And as far as I know, there
never was consensus for it.

> Plus, wouldn't it be better to integrate the functionality of any
> wrapper script in the emacsclient binary directly?

If there was consensus on a functionality that needed to be handled in
either a wrapper-script or in the emacsclient-binary itself, then yes.
But I don't think there is such a consensus.


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. 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.

Still, I know I'm not the only one who runs into the reported error
which makes emacsclient.desktop unusable.

Personally, I suggest to use, as Exec entry in emacsclient.desktop, a
simple one-liner that does not involve a shell-invocation, because it
will work for everyone.

In the long run, we might consider to: (1.) Use a similarly simple
one-liner as Exec entry, but also pass something like --xdg. (2.)
Provide Emacs users a customizable Elisp variable that specifies the
behavior of Emacsclient when passed --xdg.

> >>     Commit: d32091199ae5de590a83f1542a01d75fba000467
> >>     Author: Ulrich Müller <ulm@gentoo.org>
> >>     Date:   Mon Dec 19 16:51:20 2022 +0100
> >>     Message:
> >>         Use `sh` rather than `placeholder` as the command name of the
> >>         shell wrapper. (Bug#60204)
> >>     Code:
> >>         Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
> >>         --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\";
> >>         else exec emacsclient --alternate-editor= --create-frame; fi"
> >>         sh %F
>
> This commit didn't do anything significant for emacsclient.desktop,

You are right. Sorry for the wrong contextualization.


[1]  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/freedesktop.scm?h=60c97924e9519361494aaf0686e28eb831a42315#n517

[2]  One patch is mentioned here [4] and can be found here [5]. Another
     patch is located here [6] but does not seem to be significant with
     regards to Exec-behavior.

[3]  https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/236#note_2169234

[4]  https://github.com/gentoo/gentoo/blob/b3c1b324d58c92ad8b19c67d4aed20ecc5e5f021/x11-misc/xdg-utils/xdg-utils-1.1.3_p20210805-r1.ebuild#L13

[5]  https://dev.gentoo.org/~sam/distfiles/x11-misc/xdg-utils/xdg-utils-1.1.3_p20200220-no-which.patch.xz

[6]  https://github.com/gentoo/gentoo/blob/b3c1b324d58c92ad8b19c67d4aed20ecc5e5f021/x11-misc/xdg-utils/files/xdg-utils-egrep.patch