bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Alexey Lebedeff via Bug reports for GNU Emacs, the Swiss army knife of text editors]

The change introduced by
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65469 doesn't work anymore
in 'generic' desktop environment (as detected by 'xdg-open').

I assume it works in some desktop environments, where `xdg-open`
delegates opening to the desktop environment itself. But there is also a
`generic` version, which tries to implent XDG specification itself.

On 2023-10-03 there was a change introduced in xdg-utils
https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=b9d3ecf8180c57dbb5ca47253898ba0553e81c60
to more strictly follow xdg specification, and only pass URL-like
arguments to programs that explicitly requested this by using '%u' or
'%U' parameters.

'etc/emacsclient.desktop' uses '%F' parameter, which should be used for
programs that do not understand the URL syntax
(https://specifications.freedesktop.org/desktop-entry-spec/latest/exec-variables.html
- section about '%f', but also applies to '%F').

"x-scheme-handler/org-protocol" is the only URL-like protocol that's
mentioned in the 'etc/emacsclient.desktop', but 'xdg-open' refuses to
use it.

Just changing '%F' to '%U' in 'etc/emacsclient.desktop' is not possible,
as it allows 'xdg-open' to pass local files as "file:/" URL's if it
wants to.

One solution would be introducing separate  .desktop file
(i.e. 'etc/emacsclient-org-protocol.desktop'), analoguous to the already
existing 'etc/emacsclient-mail.desktop' (which uses '%u').


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.0)
Repository revision: 9cfd13ff44e8d6f56a1025207c833ab45a7d51ba
Repository branch: master
System Description: NixOS 24.05 (Uakari)

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Eli Zaretskii]

> Date: Thu, 21 Nov 2024 18:53:21 +0000
> From:  Alexey Lebedeff via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> The change introduced by
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65469 doesn't work anymore
> in 'generic' desktop environment (as detected by 'xdg-open').
> 
> I assume it works in some desktop environments, where `xdg-open`
> delegates opening to the desktop environment itself. But there is also a
> `generic` version, which tries to implent XDG specification itself.
> 
> On 2023-10-03 there was a change introduced in xdg-utils
> https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=b9d3ecf8180c57dbb5ca47253898ba0553e81c60
> to more strictly follow xdg specification, and only pass URL-like
> arguments to programs that explicitly requested this by using '%u' or
> '%U' parameters.
> 
> 'etc/emacsclient.desktop' uses '%F' parameter, which should be used for
> programs that do not understand the URL syntax
> (https://specifications.freedesktop.org/desktop-entry-spec/latest/exec-variables.html
> - section about '%f', but also applies to '%F').
> 
> "x-scheme-handler/org-protocol" is the only URL-like protocol that's
> mentioned in the 'etc/emacsclient.desktop', but 'xdg-open' refuses to
> use it.
> 
> Just changing '%F' to '%U' in 'etc/emacsclient.desktop' is not possible,
> as it allows 'xdg-open' to pass local files as "file:/" URL's if it
> wants to.
> 
> One solution would be introducing separate  .desktop file
> (i.e. 'etc/emacsclient-org-protocol.desktop'), analoguous to the already
> existing 'etc/emacsclient-mail.desktop' (which uses '%u').

Ihor, could you please look into this?

(Each time such issues pop up, I regret again that we agreed to
include these *.desktop files in our source tree, sigh.)

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> (Each time such issues pop up, I regret again that we agreed to
> include these *.desktop files in our source tree, sigh.)

Part of the issue with the desktop files is that someone of some them
try to execute multiple lines of shell script in them which can always
create issues.

It would be much better if desktop file calls only emacsclient
and it takes care by itself if DISPLAY is set and doesn't use sh.

Can Emacs handle file:/ URI's? If so simply changing from %F to %U would
be an option.

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Eli Zaretskii]

Ping! Ihor, can you please look into this?

> Cc: 74467@debbugs.gnu.org
> Date: Sat, 23 Nov 2024 15:12:35 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 21 Nov 2024 18:53:21 +0000
> > From:  Alexey Lebedeff via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > 
> > The change introduced by
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65469 doesn't work anymore
> > in 'generic' desktop environment (as detected by 'xdg-open').
> > 
> > I assume it works in some desktop environments, where `xdg-open`
> > delegates opening to the desktop environment itself. But there is also a
> > `generic` version, which tries to implent XDG specification itself.
> > 
> > On 2023-10-03 there was a change introduced in xdg-utils
> > https://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=b9d3ecf8180c57dbb5ca47253898ba0553e81c60
> > to more strictly follow xdg specification, and only pass URL-like
> > arguments to programs that explicitly requested this by using '%u' or
> > '%U' parameters.
> > 
> > 'etc/emacsclient.desktop' uses '%F' parameter, which should be used for
> > programs that do not understand the URL syntax
> > (https://specifications.freedesktop.org/desktop-entry-spec/latest/exec-variables.html
> > - section about '%f', but also applies to '%F').
> > 
> > "x-scheme-handler/org-protocol" is the only URL-like protocol that's
> > mentioned in the 'etc/emacsclient.desktop', but 'xdg-open' refuses to
> > use it.
> > 
> > Just changing '%F' to '%U' in 'etc/emacsclient.desktop' is not possible,
> > as it allows 'xdg-open' to pass local files as "file:/" URL's if it
> > wants to.
> > 
> > One solution would be introducing separate  .desktop file
> > (i.e. 'etc/emacsclient-org-protocol.desktop'), analoguous to the already
> > existing 'etc/emacsclient-mail.desktop' (which uses '%u').
> 
> Ihor, could you please look into this?
> 
> (Each time such issues pop up, I regret again that we agreed to
> include these *.desktop files in our source tree, sigh.)
> 
> 
> 
> 

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Ihor Radchenko]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> One solution would be introducing separate  .desktop file
>> (i.e. 'etc/emacsclient-org-protocol.desktop'), analoguous to the already
>> existing 'etc/emacsclient-mail.desktop' (which uses '%u').
>
> Ihor, could you please look into this?

I am attaching an *untested* patch that implements a new .desktop file.
Note that an alternative could be handling file:// URIs by Emacs. Your call.

> (Each time such issues pop up, I regret again that we agreed to
> include these *.desktop files in our source tree, sigh.)

We are obliged to cooperate with other parts of GNU toolchain, don't we?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-etc-emacsclient.desktop-Fix-handling-org-protocol-UR.patch --]
[-- Type: text/x-patch, Size: 2416 bytes --]

From 1b5148c8a7fe995adcfae302e48a87a039eed8a8 Mon Sep 17 00:00:00 2001
Message-ID: <1b5148c8a7fe995adcfae302e48a87a039eed8a8.1734377491.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Mon, 16 Dec 2024 20:28:28 +0100
Subject: [PATCH] etc/emacsclient.desktop: Fix handling org-protocol URIs
 (bug#74467)

* etc/emacsclient-org-protocol.desktop: New file registering
x-scheme-handler/org-protocol URI handler.  This has to be a separate
file because new versions of xdg-utils demand using %u or %U in order to
open URIs.
* etc/emacsclient.desktop: Remove x-scheme-handler/org-protocol from
MimeType.  It does not have any effect in the newer xdg-utils.
---
 etc/emacsclient-org-protocol.desktop | 13 +++++++++++++
 etc/emacsclient.desktop              |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 etc/emacsclient-org-protocol.desktop

diff --git a/etc/emacsclient-org-protocol.desktop b/etc/emacsclient-org-protocol.desktop
new file mode 100644
index 00000000000..92cde0e7130
--- /dev/null
+++ b/etc/emacsclient-org-protocol.desktop
@@ -0,0 +1,13 @@
+[Desktop Entry]
+Name=Emacs (Client)
+GenericName=Text Editor
+Comment=Handle Org protocol URI
+MimeType=x-scheme-handler/org-protocol;
+Exec=sh -c "exec emacsclient --alternate-editor= --create-frame" sh %u
+Icon=emacs
+Type=Application
+Terminal=false
+Categories=Development;TextEditor;
+StartupNotify=true
+StartupWMClass=Emacs
+Keywords=emacsclient;org-protocol
\ No newline at end of file
diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
index 4395d3b02bc..a9f840c7033 100644
--- a/etc/emacsclient.desktop
+++ b/etc/emacsclient.desktop
@@ -2,7 +2,7 @@
 Name=Emacs (Client)
 GenericName=Text Editor
 Comment=Edit text
-MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;x-scheme-handler/org-protocol;
+MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
 Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F
 Icon=emacs
 Type=Application
-- 
2.47.1


[-- Attachment #3: Type: text/plain, Size: 223 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Alexey Lebedeff <binarin@binarin.info>, 74467@debbugs.gnu.org
> Date: Mon, 16 Dec 2024 19:34:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> One solution would be introducing separate  .desktop file
> >> (i.e. 'etc/emacsclient-org-protocol.desktop'), analoguous to the already
> >> existing 'etc/emacsclient-mail.desktop' (which uses '%u').
> >
> > Ihor, could you please look into this?
> 
> I am attaching an *untested* patch that implements a new .desktop file.

Thanks.  Let's see if someone objects.

> Note that an alternative could be handling file:// URIs by Emacs. Your call.

I thought we already did?

> > (Each time such issues pop up, I regret again that we agreed to
> > include these *.desktop files in our source tree, sigh.)
> 
> We are obliged to cooperate with other parts of GNU toolchain, don't we?

To some extent, yes.  This one goes waaaay beyond that.  I don't
understand why Emacs must come with these files, instead of the
desktop folks developing and keeping them up to date.  There's nothing
specific to Emacs in these files, just a lot of XDG and shell
trickery.

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: Alexey Lebedeff <binarin@binarin.info>, 74467@debbugs.gnu.org
>> Date: Mon, 16 Dec 2024 19:34:01 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> One solution would be introducing separate  .desktop file
>> >> (i.e. 'etc/emacsclient-org-protocol.desktop'), analoguous to the already
>> >> existing 'etc/emacsclient-mail.desktop' (which uses '%u').
>> >
>> > Ihor, could you please look into this?
>> 
>> I am attaching an *untested* patch that implements a new .desktop file.
>
> Thanks.  Let's see if someone objects.
>
>> Note that an alternative could be handling file:// URIs by Emacs. Your call.
>
> I thought we already did?

Not really if I open Emacs with a file uri such as
file:///home/bidar/test.sh /home/bidar/home/bidar/test.sh will be
opened.

Would it be possible to call file-name-handlers if a path starts with
'$uri-name://' for the files passed to Emacs or Emacsclient?

>> > (Each time such issues pop up, I regret again that we agreed to
>> > include these *.desktop files in our source tree, sigh.)
>> 
>> We are obliged to cooperate with other parts of GNU toolchain, don't we?
>
> To some extent, yes.  This one goes waaaay beyond that.  I don't
> understand why Emacs must come with these files, instead of the
> desktop folks developing and keeping them up to date.  There's nothing
> specific to Emacs in these files, just a lot of XDG and shell
> trickery.

No application I have seen so far does require shell trickery in their
desktop files. Most of one or two desktop files with some metadata and
the commands to call and that's it.

It would be easier for Emacs to follow closer to the standard instead
asking for separate implementations. I don't know how this could get any
simpler. Maybe some scripts to generate desktop files for Emacs
packages if there is no for separate desktop files per modes e.g. a
desktop file for Gnus or Info mode.

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Ihor Radchenko <yantar92@posteo.net>,  74467@debbugs.gnu.org,
>   binarin@binarin.info
> Date: Mon, 16 Dec 2024 23:07:26 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Note that an alternative could be handling file:// URIs by Emacs. Your call.
> >
> > I thought we already did?
> 
> Not really if I open Emacs with a file uri such as
> file:///home/bidar/test.sh /home/bidar/home/bidar/test.sh will be
> opened.

Try

  M-x browse-url RET file:///home/bidar/test.sh RET

Or even better:

  M-x url-handler-mode RET
  C-x C-f file:///home/bidar/test.sh RET

> Would it be possible to call file-name-handlers if a path starts with
> '$uri-name://' for the files passed to Emacs or Emacsclient?

Isn't that what the above does already?

> >> We are obliged to cooperate with other parts of GNU toolchain, don't we?
> >
> > To some extent, yes.  This one goes waaaay beyond that.  I don't
> > understand why Emacs must come with these files, instead of the
> > desktop folks developing and keeping them up to date.  There's nothing
> > specific to Emacs in these files, just a lot of XDG and shell
> > trickery.
> 
> No application I have seen so far does require shell trickery in their
> desktop files. Most of one or two desktop files with some metadata and
> the commands to call and that's it.
> 
> It would be easier for Emacs to follow closer to the standard instead
> asking for separate implementations. I don't know how this could get any
> simpler. Maybe some scripts to generate desktop files for Emacs
> packages if there is no for separate desktop files per modes e.g. a
> desktop file for Gnus or Info mode.

Are you sure you understand all the expectations from the emacs.*
desktop files we have?  There were quite a few bug reports about that,
so if the files themselves don't tell enough, I suggest to look in the
bug-tracker archives.  One thing is clear to me, after seeing quite a
lot of discussions like this one: there's nothing simple about these
files.  And if you haven't yet seen this with other applications, then
perhaps Emacs is special in this regard (as well).

bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully functional

[Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Ihor Radchenko <yantar92@posteo.net>,  74467@debbugs.gnu.org,
>>   binarin@binarin.info
>> Date: Mon, 16 Dec 2024 23:07:26 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Note that an alternative could be handling file:// URIs by Emacs. Your call.
>> >
>> > I thought we already did?
>> 
>> Not really if I open Emacs with a file uri such as
>> file:///home/bidar/test.sh /home/bidar/home/bidar/test.sh will be
>> opened.
>
> Try
>
>   M-x browse-url RET file:///home/bidar/test.sh RET
>
> Or even better:
>
>   M-x url-handler-mode RET
>   C-x C-f file:///home/bidar/test.sh RET

For %U to work Emacs would also have to understand URI's as command-line arguments
when starting Emacs or calling emacsclient.

>> Would it be possible to call file-name-handlers if a path starts with
>> '$uri-name://' for the files passed to Emacs or Emacsclient?
>
> Isn't that what the above does already?

Yes but what I was referring to that these would be called also when an
URI is passed to Emacs via the command-line.

>> >> We are obliged to cooperate with other parts of GNU toolchain, don't we?
>> >
>> > To some extent, yes.  This one goes waaaay beyond that.  I don't
>> > understand why Emacs must come with these files, instead of the
>> > desktop folks developing and keeping them up to date.  There's nothing
>> > specific to Emacs in these files, just a lot of XDG and shell
>> > trickery.
>> 
>> No application I have seen so far does require shell trickery in their
>> desktop files. Most of one or two desktop files with some metadata and
>> the commands to call and that's it.
>> 
>> It would be easier for Emacs to follow closer to the standard instead
>> asking for separate implementations. I don't know how this could get any
>> simpler. Maybe some scripts to generate desktop files for Emacs
>> packages if there is no for separate desktop files per modes e.g. a
>> desktop file for Gnus or Info mode.
>
> Are you sure you understand all the expectations from the emacs.*
> desktop files we have?  There were quite a few bug reports about that,
> so if the files themselves don't tell enough, I suggest to look in the
> bug-tracker archives.  One thing is clear to me, after seeing quite a
> lot of discussions like this one: there's nothing simple about these
> files.  And if you haven't yet seen this with other applications, then
> perhaps Emacs is special in this regard (as well).

I'm not sure if I understand all of them but part of the issue is that
Emacs embeds relatively complicated shell script code in the Exec= key,
writing a small set of elisp in these is also not so clean but still ok.

All other applications I have seen put the parsing of arguments or
eventual handling of variables not being set inside the application
itself. All other situational logic is limited to a simple set of
program arguments.
Also if the command-line arguments to Emacs first have to go through a shell
it gets rather messy when preserving the arguments.