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

Previous Next

To reply to this bug, email your comments to 74467 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexey Lebedeff <binarin <at> binarin.info>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50;
 org-protocol emacsclient.desktop change is not fully functional
Date: Thu, 21 Nov 2024 18:53:21 +0000

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)

Message #8 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexey Lebedeff <binarin <at> binarin.info>,
 Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50;
 org-protocol emacsclient.desktop change is not fully functional
Date: Sat, 23 Nov 2024 15:12:35 +0200

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

Message #11 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, Alexey Lebedeff <binarin <at> binarin.info>,
 Ihor Radchenko <yantar92 <at> posteo.net>
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sat, 23 Nov 2024 21:58:22 +0200

Eli Zaretskii <eliz <at> 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.

Message #14 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: yantar92 <at> posteo.net
Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50;
 org-protocol emacsclient.desktop change is not fully functional
Date: Sat, 07 Dec 2024 14:17:41 +0200

Ping! Ihor, can you please look into this?

> Cc: 74467 <at> debbugs.gnu.org
> Date: Sat, 23 Nov 2024 15:12:35 +0200
> From: Eli Zaretskii <eliz <at> 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 <at> 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.)
> 
> 
> 
> 

Message #17 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, Alexey Lebedeff <binarin <at> binarin.info>
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 16 Dec 2024 19:34:01 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> 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?

[0001-etc-emacsclient.desktop-Fix-handling-org-protocol-UR.patch (text/x-patch, inline)]

From 1b5148c8a7fe995adcfae302e48a87a039eed8a8 Mon Sep 17 00:00:00 2001
Message-ID: <1b5148c8a7fe995adcfae302e48a87a039eed8a8.1734377491.git.yantar92 <at> posteo.net>
From: Ihor Radchenko <yantar92 <at> 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

[Message part 3 (text/plain, inline)]

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

Message #20 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 16 Dec 2024 22:01:56 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Alexey Lebedeff <binarin <at> binarin.info>, 74467 <at> debbugs.gnu.org
> Date: Mon, 16 Dec 2024 19:34:01 +0000
> 
> Eli Zaretskii <eliz <at> 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.

Message #23 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
 binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 16 Dec 2024 23:07:26 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> Cc: Alexey Lebedeff <binarin <at> binarin.info>, 74467 <at> debbugs.gnu.org
>> Date: Mon, 16 Dec 2024 19:34:01 +0000
>> 
>> Eli Zaretskii <eliz <at> 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.

Message #26 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Tue, 17 Dec 2024 14:15:14 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  74467 <at> debbugs.gnu.org,
>   binarin <at> binarin.info
> Date: Mon, 16 Dec 2024 23:07:26 +0200
> 
> Eli Zaretskii <eliz <at> 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).

Message #29 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Tue, 17 Dec 2024 15:00:17 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  74467 <at> debbugs.gnu.org,
>>   binarin <at> binarin.info
>> Date: Mon, 16 Dec 2024 23:07:26 +0200
>> 
>> Eli Zaretskii <eliz <at> 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.

Message #32 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: yantar92 <at> posteo.net
Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50;
 org-protocol emacsclient.desktop change is not fully functional
Date: Sat, 28 Dec 2024 13:37:34 +0200

> Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
> Date: Mon, 16 Dec 2024 22:01:56 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Ihor Radchenko <yantar92 <at> posteo.net>
> > Cc: Alexey Lebedeff <binarin <at> binarin.info>, 74467 <at> debbugs.gnu.org
> > Date: Mon, 16 Dec 2024 19:34:01 +0000
> > 
> > Eli Zaretskii <eliz <at> 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?

Ping!  Since we already know how to handle file:// UTIs, what would
the solution using that look like?

Message #35 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Thu, 02 Jan 2025 22:02:05 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
>> Date: Mon, 16 Dec 2024 22:01:56 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> > From: Ihor Radchenko <yantar92 <at> posteo.net>
>> > Cc: Alexey Lebedeff <binarin <at> binarin.info>, 74467 <at> debbugs.gnu.org
>> > Date: Mon, 16 Dec 2024 19:34:01 +0000
>> > 
>> > Eli Zaretskii <eliz <at> 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?
>
> Ping!  Since we already know how to handle file:// UTIs, what would
> the solution using that look like?

Would it work to add a file-handler for uris to call?
Further change so that if the file argument does start with '^.*://'  to
not append '/:'.

With these changes Emacs can handle any url forwarded to Emacs. We might
also want signal an error if the uri send to Emacs was not handled by
browse-url.

Message #38 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sat, 04 Jan 2025 15:18:22 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: yantar92 <at> posteo.net,  74467 <at> debbugs.gnu.org,  binarin <at> binarin.info
> Date: Thu, 02 Jan 2025 22:02:05 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
> >> Date: Mon, 16 Dec 2024 22:01:56 +0200
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >> 
> >> > From: Ihor Radchenko <yantar92 <at> posteo.net>
> >> > Cc: Alexey Lebedeff <binarin <at> binarin.info>, 74467 <at> debbugs.gnu.org
> >> > Date: Mon, 16 Dec 2024 19:34:01 +0000
> >> > 
> >> > Eli Zaretskii <eliz <at> 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?
> >
> > Ping!  Since we already know how to handle file:// UTIs, what would
> > the solution using that look like?
> 
> Would it work to add a file-handler for uris to call?

Isn't that what we already do when we visit files given by file://
URI?

Message #41 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 00:07:37 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: yantar92 <at> posteo.net,  74467 <at> debbugs.gnu.org,  binarin <at> binarin.info
>> Date: Thu, 02 Jan 2025 22:02:05 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: 74467 <at> debbugs.gnu.org, binarin <at> binarin.info
>> >> Date: Mon, 16 Dec 2024 22:01:56 +0200
>> >> From: Eli Zaretskii <eliz <at> gnu.org>
>> >> 
>> >> > From: Ihor Radchenko <yantar92 <at> posteo.net>
>> >> > Cc: Alexey Lebedeff <binarin <at> binarin.info>, 74467 <at> debbugs.gnu.org
>> >> > Date: Mon, 16 Dec 2024 19:34:01 +0000
>> >> > 
>> >> > Eli Zaretskii <eliz <at> 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?
>> >
>> > Ping!  Since we already know how to handle file:// UTIs, what would
>> > the solution using that look like?
>> 
>> Would it work to add a file-handler for uris to call?
>
> Isn't that what we already do when we visit files given by file://
> URI?

No not for file argument when Emacs stars or in emacsclient. We append
/: and then call find_file_handler.

Is the .*:/ part ignore when calling find-file-file interactively?

When I call find-file in eshell with someting like
"file:///etc/os-release" I get this:

Debugger entered--entering a function:
* directory-abbrev-apply("/home/bidar/dev/emacs/emacs/src/file:/etc/os-release")
* abbreviate-file-name("/home/bidar/dev/emacs/emacs/src/file:/etc/os-release")
* find-file-noselect("file:///etc/os-release" nil nil nil)
* #<subr find-file>("file:///etc/os-release")
* apply(#<subr find-file> "file:///etc/os-release")
* find-file("file:///etc/os-release")
  eval((find-file "file:///etc/os-release"))
 

Message #44 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 08:39:54 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: yantar92 <at> posteo.net,  74467 <at> debbugs.gnu.org,  binarin <at> binarin.info
> Date: Sun, 05 Jan 2025 00:07:37 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> >> > Note that an alternative could be handling file:// URIs by Emacs. Your call.
> >> >> 
> >> >> I thought we already did?
> >> >
> >> > Ping!  Since we already know how to handle file:// UTIs, what would
> >> > the solution using that look like?
> >> 
> >> Would it work to add a file-handler for uris to call?
> >
> > Isn't that what we already do when we visit files given by file://
> > URI?
> 
> No not for file argument when Emacs stars or in emacsclient. We append
> /: and then call find_file_handler.

I didn't mean this works OOTB.  Some changes are surely needed.  Ihor
seemed to say that if this can be supported, there could be an
alternative patch for fixing this issue, and I'd like to see that
alternative patch to decide which one is simpler and/or more elegant.

Message #47 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>, binarin <at> binarin.info,
 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 08:55:54 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> ...  Ihor
> seemed to say that if this can be supported, there could be an
> alternative patch for fixing this issue, and I'd like to see that
> alternative patch to decide which one is simpler and/or more elegant.

See the attached.
If Emacs can handle file URIs, we can simply use %U field code.

[alternative.diff (text/x-patch, inline)]

diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
index 4395d3b02bc..c339ac93687 100644
--- a/etc/emacsclient.desktop
+++ b/etc/emacsclient.desktop
@@ -3,7 +3,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;
-Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F
+Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %U
 Icon=emacs
 Type=Application
 Terminal=false

[Message part 3 (text/plain, inline)]

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

Message #50 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 20:13:09 +0200

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> ...  Ihor
>> seemed to say that if this can be supported, there could be an
>> alternative patch for fixing this issue, and I'd like to see that
>> alternative patch to decide which one is simpler and/or more elegant.
>
> See the attached.
> If Emacs can handle file URIs, we can simply use %U field code.
>
> diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
> index 4395d3b02bc..c339ac93687 100644
> --- a/etc/emacsclient.desktop
> +++ b/etc/emacsclient.desktop
> @@ -3,7 +3,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;
> -Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F
> +Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %U

Do we need the shell code here? if DISPLAY is defined emacsclient could
shurely forward it to Emacs.

Shellcode is part of the issue.

Message #53 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 20:20:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: yantar92 <at> posteo.net,  74467 <at> debbugs.gnu.org,  binarin <at> binarin.info
>> Date: Sun, 05 Jan 2025 00:07:37 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> >> > Note that an alternative could be handling file:// URIs by Emacs. Your call.
>> >> >> 
>> >> >> I thought we already did?
>> >> >
>> >> > Ping!  Since we already know how to handle file:// UTIs, what would
>> >> > the solution using that look like?
>> >> 
>> >> Would it work to add a file-handler for uris to call?
>> >
>> > Isn't that what we already do when we visit files given by file://
>> > URI?
>> 
>> No not for file argument when Emacs stars or in emacsclient. We append
>> /: and then call find_file_handler.
>
> I didn't mean this works OOTB.  Some changes are surely needed.  Ihor
> seemed to say that if this can be supported, there could be an
> alternative patch for fixing this issue, and I'd like to see that
> alternative patch to decide which one is simpler and/or more elegant.

I know you meant that. My point was to describe what is the problem.
I wanted to understand what's going on as I don't know so much about the
code which is below the Lisp code and how it interacts with the C-code.

Do I understand correctly that when Emacs starts it tries to find the
file-handler in C but the call to the handler is done in Lisp code?

It is very interesting to learn how Emacs works on this level,
especially when going down into (X)Emacs past. Anyways that is another
topic.

Message #56 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 18:36:45 +0000

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

>> -Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F
>> +Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %U
>
> Do we need the shell code here? if DISPLAY is defined emacsclient could
> shurely forward it to Emacs.

I think that reasons why sh is there have nothing to do with the issue
at hand.

> Shellcode is part of the issue.

How so?
The first message in this thread described exactly why the old version
stopped working:

    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.

After the above change, %F in our .desktop file prevents xdg-open from
using it for opening URIs. Any URIs, not just org-protocol and co.

So, %U should fix it, except that it will also signal to xdg-open that
Emacs can handle file:// URI as well; so we need to make sure that
file:// URIs can be opened just fine.

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

Message #59 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 21:11:19 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: yantar92 <at> posteo.net,  74467 <at> debbugs.gnu.org,  binarin <at> binarin.info
> Date: Sun, 05 Jan 2025 20:20:40 +0200
> 
> Do I understand correctly that when Emacs starts it tries to find the
> file-handler in C but the call to the handler is done in Lisp code?

AFAIR, file-handlers are looked for on both C and Lisp level.  What
matters is the level on which the operation is implemented.  If it's
implemented in C, we must look for the handler in C, otherwise we can
look for it in Lisp.  find-file-name-handler is a primitive
implemented in C, but you can call it both from C and from Lisp.

Message #62 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 05 Jan 2025 23:31:51 +0200

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
>
>>> -Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
>>> --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else
>>> exec emacsclient --alternate-editor= --create-frame; fi" sh %F
>>> +Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient
>>> --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else
>>> exec emacsclient --alternate-editor= --create-frame; fi" sh %U
>>
>> Do we need the shell code here? if DISPLAY is defined emacsclient could
>> shurely forward it to Emacs.
>
> I think that reasons why sh is there have nothing to do with the issue
> at hand.
>
>> Shellcode is part of the issue.
>
> How so?
> The first message in this thread described exactly why the old version
> stopped working:
>
>     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.

Calling a shell and then the program is more complicated as the argument
supplied to Emacs first run through the shell and then Emacs making the
arguments subject to the shell parsing rules.

> After the above change, %F in our .desktop file prevents xdg-open from
> using it for opening URIs. Any URIs, not just org-protocol and co.
>
> So, %U should fix it, except that it will also signal to xdg-open that
> Emacs can handle file:// URI as well; so we need to make sure that
> file:// URIs can be opened just fine.

It does fix that but dropping the shell in this context helps to avoid any
later potential issues.

Message #65 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 06 Jan 2025 18:44:01 +0000

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

> Calling a shell and then the program is more complicated as the argument
> supplied to Emacs first run through the shell and then Emacs making the
> arguments subject to the shell parsing rules.
> ...
> It does fix that but dropping the shell in this context helps to avoid any
> later potential issues.

Maybe. But how does it have anything to do with the particular bug we
are discussing now?

If you have ideas how to improve the sh command in the .desktop file, I
suggest moving such discussion to emacs-devel.

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

Message #68 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Tue, 07 Jan 2025 10:05:02 +0200

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Björn Bidar <bjorn.bidar <at> thaodan.de> writes:
>
>> Calling a shell and then the program is more complicated as the argument
>> supplied to Emacs first run through the shell and then Emacs making the
>> arguments subject to the shell parsing rules.
>> ...
>> It does fix that but dropping the shell in this context helps to avoid any
>> later potential issues.
>
> Maybe. But how does it have anything to do with the particular bug we
> are discussing now?
I'm not sure I merely mentioned it because of the issues we have been
facing regarding the desktop files.

> If you have ideas how to improve the sh command in the .desktop file, I
> suggest moving such discussion to emacs-devel.

I suggest to call Emacsclient without sh but yeah good call.

Message #71 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sat, 11 Jan 2025 13:09:56 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
>  74467 <at> debbugs.gnu.org,
>  binarin <at> binarin.info
> Date: Sun, 05 Jan 2025 08:55:54 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > ...  Ihor
> > seemed to say that if this can be supported, there could be an
> > alternative patch for fixing this issue, and I'd like to see that
> > alternative patch to decide which one is simpler and/or more elegant.
> 
> See the attached.
> If Emacs can handle file URIs, we can simply use %U field code.
> 
> diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
> index 4395d3b02bc..c339ac93687 100644
> --- a/etc/emacsclient.desktop
> +++ b/etc/emacsclient.desktop
> @@ -3,7 +3,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;
> -Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F
> +Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %U
>  Icon=emacs
>  Type=Application
>  Terminal=false

Thanks, but I think we need to turn on the url-handler-mode before
Emacs can visit files specified as file:// URIs.

Message #74 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Alexey Lebedeff <binarin <at> binarin.info>
To: Eli Zaretskii <eliz <at> gnu.org>, Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 20 Jan 2025 11:33:55 +0100

On 23-11-2024 14:12, Eli Zaretskii wrote:
>> 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 <at> 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.)

Understandable. But I think it's still better than letting users to 
figure out all the quirks on their own.

Since then I've tried to set-up org-protocol on a Windows machine, and 
the experience was even worse: a few registry edits, and a custom binary 
(https://github.com/coldacid/org-protocol-w32-handler) to fix encoding 
issues. OK, I can do it myself, but maybe it's better to do it as a part 
of the binary distribution - especially given that org-mode is a part of 
Emacs now.

Message #77 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexey Lebedeff <binarin <at> binarin.info>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 20 Jan 2025 15:13:46 +0200

> Date: Mon, 20 Jan 2025 11:33:55 +0100
> Cc: 74467 <at> debbugs.gnu.org
> From: Alexey Lebedeff <binarin <at> binarin.info>
> 
> On 23-11-2024 14:12, Eli Zaretskii wrote:
> >> 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 <at> 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.)
> 
> Understandable. But I think it's still better than letting users to 
> figure out all the quirks on their own.

To clarify: I think this is for distros to figure out, not for users.

> Since then I've tried to set-up org-protocol on a Windows machine, and 
> the experience was even worse: a few registry edits, and a custom binary 
> (https://github.com/coldacid/org-protocol-w32-handler) to fix encoding 
> issues. OK, I can do it myself, but maybe it's better to do it as a part 
> of the binary distribution - especially given that org-mode is a part of 
> Emacs now.

See above: doing this as part of the binary distribution is perfectly
fine by me.  I just don't think it's our job as the upstream project,
because it requires too intimate knowledge of the various desktops and
their idiosyncrasies.

Message #80 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: yantar92 <at> posteo.net
Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50;
 org-protocol emacsclient.desktop change is not fully functional
Date: Sat, 25 Jan 2025 10:41:49 +0200

> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
> Date: Sat, 11 Jan 2025 13:09:56 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Ihor Radchenko <yantar92 <at> posteo.net>
> > Cc: Björn Bidar <bjorn.bidar <at> thaodan.de>,
> >  74467 <at> debbugs.gnu.org,
> >  binarin <at> binarin.info
> > Date: Sun, 05 Jan 2025 08:55:54 +0000
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > > ...  Ihor
> > > seemed to say that if this can be supported, there could be an
> > > alternative patch for fixing this issue, and I'd like to see that
> > > alternative patch to decide which one is simpler and/or more elegant.
> > 
> > See the attached.
> > If Emacs can handle file URIs, we can simply use %U field code.
> > 
> > diff --git a/etc/emacsclient.desktop b/etc/emacsclient.desktop
> > index 4395d3b02bc..c339ac93687 100644
> > --- a/etc/emacsclient.desktop
> > +++ b/etc/emacsclient.desktop
> > @@ -3,7 +3,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;
> > -Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %F
> > +Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" sh %U
> >  Icon=emacs
> >  Type=Application
> >  Terminal=false
> 
> Thanks, but I think we need to turn on the url-handler-mode before
> Emacs can visit files specified as file:// URIs.

Ping!

Message #83 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 16 Mar 2025 14:07:29 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > > ...  Ihor
>> > > seemed to say that if this can be supported, there could be an
>> > > alternative patch for fixing this issue, and I'd like to see that
>> > > alternative patch to decide which one is simpler and/or more elegant.
>> > 
>> > See the attached.
>> > If Emacs can handle file URIs, we can simply use %U field code.
>>  ...
>> Thanks, but I think we need to turn on the url-handler-mode before
>> Emacs can visit files specified as file:// URIs.
>
> Ping!

But isn't `url-handler-mode' doing much more than just allowing URIs in
emacs/emacsclient arguments? Maybe one can make a more limited version
of url-handler-mode that would be safe to enable to by default?

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

Message #86 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 74467 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 16 Mar 2025 16:55:26 +0200

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> > > ...  Ihor
>>> > > seemed to say that if this can be supported, there could be an
>>> > > alternative patch for fixing this issue, and I'd like to see that
>>> > > alternative patch to decide which one is simpler and/or more elegant.
>>> > 
>>> > See the attached.
>>> > If Emacs can handle file URIs, we can simply use %U field code.
>>>  ...
>>> Thanks, but I think we need to turn on the url-handler-mode before
>>> Emacs can visit files specified as file:// URIs.
>>
>> Ping!
>
> But isn't `url-handler-mode' doing much more than just allowing URIs in
> emacs/emacsclient arguments? Maybe one can make a more limited version
> of url-handler-mode that would be safe to enable to by default?

Are there any security issues with enabling url-handler-mode by default?

Url-handler mode adds the url-file-handler to the file-name-handler so
it can handle URI's. 

As a side-note maybe the handler should be called URI-handler instead of
URL-handler as it handlers URI types which are not URL's.

Alternatively the handler could only handle local URI's by default and
enable remote URI's if enabled.

Message #89 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 16 Mar 2025 17:17:19 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 14:07:29 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > > ...  Ihor
> >> > > seemed to say that if this can be supported, there could be an
> >> > > alternative patch for fixing this issue, and I'd like to see that
> >> > > alternative patch to decide which one is simpler and/or more elegant.
> >> > 
> >> > See the attached.
> >> > If Emacs can handle file URIs, we can simply use %U field code.
> >>  ...
> >> Thanks, but I think we need to turn on the url-handler-mode before
> >> Emacs can visit files specified as file:// URIs.
> >
> > Ping!
> 
> But isn't `url-handler-mode' doing much more than just allowing URIs in
> emacs/emacsclient arguments? Maybe one can make a more limited version
> of url-handler-mode that would be safe to enable to by default?

That would be also fine by me.

Message #92 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>,
 binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 16 Mar 2025 20:52:22 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
>> Date: Sun, 16 Mar 2025 14:07:29 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> > > ...  Ihor
>> >> > > seemed to say that if this can be supported, there could be an
>> >> > > alternative patch for fixing this issue, and I'd like to see that
>> >> > > alternative patch to decide which one is simpler and/or more elegant.
>> >> > 
>> >> > See the attached.
>> >> > If Emacs can handle file URIs, we can simply use %U field code.
>> >>  ...
>> >> Thanks, but I think we need to turn on the url-handler-mode before
>> >> Emacs can visit files specified as file:// URIs.
>> >
>> > Ping!
>> 
>> But isn't `url-handler-mode' doing much more than just allowing URIs in
>> emacs/emacsclient arguments? Maybe one can make a more limited version
>> of url-handler-mode that would be safe to enable to by default?
>
> That would be also fine by me.

What would that look like? Could that be like suggested earlier to be a
version only allowing local URIs?

Message #95 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Sun, 16 Mar 2025 21:56:30 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  binarin <at> binarin.info,
>   74467 <at> debbugs.gnu.org
> Date: Sun, 16 Mar 2025 20:52:22 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Ihor Radchenko <yantar92 <at> posteo.net>
> >> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
> >> Date: Sun, 16 Mar 2025 14:07:29 +0000
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> > > ...  Ihor
> >> >> > > seemed to say that if this can be supported, there could be an
> >> >> > > alternative patch for fixing this issue, and I'd like to see that
> >> >> > > alternative patch to decide which one is simpler and/or more elegant.
> >> >> > 
> >> >> > See the attached.
> >> >> > If Emacs can handle file URIs, we can simply use %U field code.
> >> >>  ...
> >> >> Thanks, but I think we need to turn on the url-handler-mode before
> >> >> Emacs can visit files specified as file:// URIs.
> >> >
> >> > Ping!
> >> 
> >> But isn't `url-handler-mode' doing much more than just allowing URIs in
> >> emacs/emacsclient arguments? Maybe one can make a more limited version
> >> of url-handler-mode that would be safe to enable to by default?
> >
> > That would be also fine by me.
> 
> What would that look like?

I don't know, I just said that anything which makes Emacs understand
file:// URLs will be fine by me.

Message #98 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 17 Mar 2025 03:16:20 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  binarin <at> binarin.info,
>>   74467 <at> debbugs.gnu.org
>> Date: Sun, 16 Mar 2025 20:52:22 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> >> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
>> >> Date: Sun, 16 Mar 2025 14:07:29 +0000
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> >> > > ...  Ihor
>> >> >> > > seemed to say that if this can be supported, there could be an
>> >> >> > > alternative patch for fixing this issue, and I'd like to see that
>> >> >> > > alternative patch to decide which one is simpler and/or more elegant.
>> >> >> > 
>> >> >> > See the attached.
>> >> >> > If Emacs can handle file URIs, we can simply use %U field code.
>> >> >>  ...
>> >> >> Thanks, but I think we need to turn on the url-handler-mode before
>> >> >> Emacs can visit files specified as file:// URIs.
>> >> >
>> >> > Ping!
>> >> 
>> >> But isn't `url-handler-mode' doing much more than just allowing URIs in
>> >> emacs/emacsclient arguments? Maybe one can make a more limited version
>> >> of url-handler-mode that would be safe to enable to by default?
>> >
>> > That would be also fine by me.
>> 
>> What would that look like?
>
> I don't know, I just said that anything which makes Emacs understand
> file:// URLs will be fine by me.

Would it work that the current uri handler is enabled by default and
enabling url-handler-mode enables URLs for it?

Message #101 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 17 Mar 2025 14:59:23 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: yantar92 <at> posteo.net,  binarin <at> binarin.info,  74467 <at> debbugs.gnu.org
> Date: Mon, 17 Mar 2025 03:16:20 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> >> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  binarin <at> binarin.info,
> >>   74467 <at> debbugs.gnu.org
> >> Date: Sun, 16 Mar 2025 20:52:22 +0200
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> From: Ihor Radchenko <yantar92 <at> posteo.net>
> >> >> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
> >> >> Date: Sun, 16 Mar 2025 14:07:29 +0000
> >> >> 
> >> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> >> 
> >> >> >> > > ...  Ihor
> >> >> >> > > seemed to say that if this can be supported, there could be an
> >> >> >> > > alternative patch for fixing this issue, and I'd like to see that
> >> >> >> > > alternative patch to decide which one is simpler and/or more elegant.
> >> >> >> > 
> >> >> >> > See the attached.
> >> >> >> > If Emacs can handle file URIs, we can simply use %U field code.
> >> >> >>  ...
> >> >> >> Thanks, but I think we need to turn on the url-handler-mode before
> >> >> >> Emacs can visit files specified as file:// URIs.
> >> >> >
> >> >> > Ping!
> >> >> 
> >> >> But isn't `url-handler-mode' doing much more than just allowing URIs in
> >> >> emacs/emacsclient arguments? Maybe one can make a more limited version
> >> >> of url-handler-mode that would be safe to enable to by default?
> >> >
> >> > That would be also fine by me.
> >> 
> >> What would that look like?
> >
> > I don't know, I just said that anything which makes Emacs understand
> > file:// URLs will be fine by me.
> 
> Would it work that the current uri handler is enabled by default and
> enabling url-handler-mode enables URLs for it?

I'm not sure I understand the proposal.  One problem with having the
uri handler active at all times is that it subtly changes how local
files whose names just happen to start with "http://" (rare, but still
legitimate) are handled.

Message #104 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 17 Mar 2025 15:25:59 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> Cc: yantar92 <at> posteo.net,  binarin <at> binarin.info,  74467 <at> debbugs.gnu.org
>> Date: Mon, 17 Mar 2025 03:16:20 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
>> >> Cc: Ihor Radchenko <yantar92 <at> posteo.net>,  binarin <at> binarin.info,
>> >>   74467 <at> debbugs.gnu.org
>> >> Date: Sun, 16 Mar 2025 20:52:22 +0200
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> >> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> >> >> Cc: bjorn.bidar <at> thaodan.de, binarin <at> binarin.info, 74467 <at> debbugs.gnu.org
>> >> >> Date: Sun, 16 Mar 2025 14:07:29 +0000
>> >> >> 
>> >> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> >> 
>> >> >> >> > > ...  Ihor
>> >> >> >> > > seemed to say that if this can be supported, there could be an
>> >> >> >> > > alternative patch for fixing this issue, and I'd like to see that
>> >> >> >> > > alternative patch to decide which one is simpler and/or more elegant.
>> >> >> >> > 
>> >> >> >> > See the attached.
>> >> >> >> > If Emacs can handle file URIs, we can simply use %U field code.
>> >> >> >>  ...
>> >> >> >> Thanks, but I think we need to turn on the url-handler-mode before
>> >> >> >> Emacs can visit files specified as file:// URIs.
>> >> >> >
>> >> >> > Ping!
>> >> >> 
>> >> >> But isn't `url-handler-mode' doing much more than just allowing URIs in
>> >> >> emacs/emacsclient arguments? Maybe one can make a more limited version
>> >> >> of url-handler-mode that would be safe to enable to by default?
>> >> >
>> >> > That would be also fine by me.
>> >> 
>> >> What would that look like?
>> >
>> > I don't know, I just said that anything which makes Emacs understand
>> > file:// URLs will be fine by me.
>> 
>> Would it work that the current uri handler is enabled by default and
>> enabling url-handler-mode enables URLs for it?
>
> I'm not sure I understand the proposal.  One problem with having the
> uri handler active at all times is that it subtly changes how local
> files whose names just happen to start with "http://" (rare, but still
> legitimate) are handled.

My proposal is to add the url-file-handler as ur-file-handler by default
and change url-handler-mode to add the url's to the URI handler.
That would make so that file URI's a handled always and the existing
behavior of url-handler-mode is kept.


Have encountered files starting with a URI prefix such as http? I
haven't had that so far. I workaround would be to always first check if
a file with such a prefix exist in the url-file-handler before trying to
process the URL/URI.

Message #107 received at 74467 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: 74467 <at> debbugs.gnu.org, yantar92 <at> posteo.net, binarin <at> binarin.info
Subject: Re: bug#74467: 31.0.50; org-protocol emacsclient.desktop change is
 not fully functional
Date: Mon, 17 Mar 2025 16:46:24 +0200

> From: Björn Bidar <bjorn.bidar <at> thaodan.de>
> Cc: yantar92 <at> posteo.net,  binarin <at> binarin.info,  74467 <at> debbugs.gnu.org
> Date: Mon, 17 Mar 2025 15:25:59 +0200
> 
> Have encountered files starting with a URI prefix such as http?

It's very easy to get that if you use wget to recursively download
sites, for example.  But yes, it's rare to see this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.