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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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