[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#74467: 31.0.50; org-protocol emacsclient.desktop change is not fully
From: |
Eli Zaretskii |
Subject: |
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@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).