Generic Elisp mechanism to declare file/URI handlers for Emacs (was: bug#65469: [PATCH] * etc/emacsclient.desktop: Make Emacs default application for org-protocol)

Generic Elisp mechanism to declare file/URI handlers for Emacs (was: bug#65469: [PATCH] * etc/emacsclient.desktop: Make Emacs default application for org-protocol)

[Ihor Radchenko]

[ moving to emacs-devel ]

Po Lu <luangruo@yahoo.com> writes:

>> I am also wondering is something similar might be done for Android build.
>> Having something like "Share with ... Emacs" might be an interesting
>> feature.
>
> I wrote this feature back in August, immediately upon this patch's
> installation in master.  Emacs registers itself as a URL handler for
> ``org-protocol://'' links, which are then provided to emacsclient.

Thanks!

Apparently, Android builds have to implement handlers in the source code
directly. This makes adding new handlers for Emacs non-trivial - one
needs to know both about .desktop file and also about Android-specific
code (and what about MacOS-specific and Windows-specific?).

Would it make sense to create a more generic mechanism to collect a list
of handlers from all the Elisp sources in Emacs and then generate
Linux/Android/etc-specific definitions automatically when Emacs is
compiled?

I imagine something akin how ;;;###autoload works - Elisp libraries that
implement handling of certain file types or URI protocols declare this
fact and then Emacs automatically pick this info, generating .desktop
files and relevant parts of Andoid
(java/org/gnu/emacs/EmacsOpenActivity.java) and whatever else necessary.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Apparently, Android builds have to implement handlers in the source code
> directly. This makes adding new handlers for Emacs non-trivial - one
> needs to know both about .desktop file and also about Android-specific
> code (and what about MacOS-specific and Windows-specific?).

Introducing a handler for a new URL scheme only requires the
introduction of a single line of Java:

  uri.getScheme ().equals ("your-protocol")

and one line of XML in AndroidManifest.xml:

        <data android:scheme="your-protocol"/>

Much easier than introducing handlers into .desktop files, which present
potential authors with a litany of pedantic rules to be followed.

> Would it make sense to create a more generic mechanism to collect a list
> of handlers from all the Elisp sources in Emacs and then generate
> Linux/Android/etc-specific definitions automatically when Emacs is
> compiled?

That's overengineering.  What in Emacs, save for org-protocol, defines
such URL handlers?  And are they particular to Emacs to the same extent
that org-protocol is, justifying Emacs's placement within the ``Open
With'' dialog on my phone?

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Apparently, Android builds have to implement handlers in the source code
>> directly. This makes adding new handlers for Emacs non-trivial - one
>> needs to know both about .desktop file and also about Android-specific
>> code (and what about MacOS-specific and Windows-specific?).
>
> Introducing a handler for a new URL scheme only requires the
> introduction of a single line of Java:
> ...

I agree that it is not difficult. But it is very easy to miss
implementing a new scheme on _all_ the supported OSes. For example, I
have no idea if Emacs even provides something similar to .desktop file
on MacOS and Windows.

>> Would it make sense to create a more generic mechanism to collect a list
>> of handlers from all the Elisp sources in Emacs and then generate
>> Linux/Android/etc-specific definitions automatically when Emacs is
>> compiled?
>
> That's overengineering.  What in Emacs, save for org-protocol, defines
> such URL handlers?  And are they particular to Emacs to the same extent
> that org-protocol is, justifying Emacs's placement within the ``Open
> With'' dialog on my phone?

I mostly thought about file type handling.
Wouldn't it be nice to allow built-in major modes also make Emacs
register as application capable to open the corresponding file
type/extension.

For example, consider that we have built-in clojure-mode at some point.
Then, it will make sense to tell OS that Emacs is able to open .clj
files. Same for any other new major mode.

Not every major mode author knows the specific ways how Emacs implements
file type handling in different OSes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> I agree that it is not difficult. But it is very easy to miss
> implementing a new scheme on _all_ the supported OSes. For example, I
> have no idea if Emacs even provides something similar to .desktop file
> on MacOS and Windows.

It does not.

> I mostly thought about file type handling.
> Wouldn't it be nice to allow built-in major modes also make Emacs
> register as application capable to open the corresponding file
> type/extension.
>
> For example, consider that we have built-in clojure-mode at some point.
> Then, it will make sense to tell OS that Emacs is able to open .clj
> files. Same for any other new major mode.
>
> Not every major mode author knows the specific ways how Emacs implements
> file type handling in different OSes.

Emacs opens all text documents, and Clojure files are a kind of text
file.

And be that as it may, operating systems use different names to
designate each kind of text file, so expecting major mode authors to
understand every one of those names is unreasonable anyway.

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> For example, consider that we have built-in clojure-mode at some point.
>> Then, it will make sense to tell OS that Emacs is able to open .clj
>> files. Same for any other new major mode.
>>
>> Not every major mode author knows the specific ways how Emacs implements
>> file type handling in different OSes.
>
> Emacs opens all text documents, and Clojure files are a kind of text
> file.

AFAIK, this is not the case. At least, for .desktop file on Linux.
Emacs opens all text/plain documents, but not all text/* documents.
In addition Emacs opens

text/english;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++;

which is a closed list. If we have something like, for example,
text/markdown, it will not be open by Emacs without explicit declaration
in the .desktop file.

> And be that as it may, operating systems use different names to
> designate each kind of text file, so expecting major mode authors to
> understand every one of those names is unreasonable anyway.

I thought that mimetypes is the common standard:
https://www.iana.org/assignments/media-types/media-types.xhtml
If not, it is indeed a problem.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> AFAIK, this is not the case. At least, for .desktop file on Linux.
> Emacs opens all text/plain documents, but not all text/* documents.
> In addition Emacs opens
>
> text/english;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++;
>
> which is a closed list. If we have something like, for example,
> text/markdown, it will not be open by Emacs without explicit declaration
> in the .desktop file.

Then maybe that should be fixed, because under Android, Emacs opens all
text/* files.  (Given that Emacs is usually the sole functioning text
editor when installed on Android systems.)

> I thought that mimetypes is the common standard:
> https://www.iana.org/assignments/media-types/media-types.xhtml
> If not, it is indeed a problem.

Does the IANA standard encompass Clojure files?

Should Emacs declare itself as being able to open all the text/* mimetypes? (was: Generic Elisp mechanism to declare file/URI handlers for Emacs)

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> text/english;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++;
>>
>> which is a closed list. If we have something like, for example,
>> text/markdown, it will not be open by Emacs without explicit declaration
>> in the .desktop file.
>
> Then maybe that should be fixed, because under Android, Emacs opens all
> text/* files.  (Given that Emacs is usually the sole functioning text
> editor when installed on Android systems.)

I am not sure if it is possible to use wildcards like this.

Nothing is said in the spec:
https://specifications.freedesktop.org/desktop-entry-spec/0.9.5/ar01s07.html

On the other hand, wildcards seems to work:
https://unix.stackexchange.com/questions/232525/mimetype-desktop-entry-for-all-image-files

So, your suggestion sounds reasonable.

>> I thought that mimetypes is the common standard:
>> https://www.iana.org/assignments/media-types/media-types.xhtml
>> If not, it is indeed a problem.
>
> Does the IANA standard encompass Clojure files?

Nope. It was just an example. Clojure files do not have a dedicated
mimetype:

$ xdg-mime query filetype ./project.clj 
text/plain

Other source code files might though. For example,

$ xdg-mime query filetype src/js.rs 
text/rust

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>

Re: Should Emacs declare itself as being able to open all the text/* mimetypes?

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Other source code files might though. For example,
>
> $ xdg-mime query filetype src/js.rs 
> text/rust

RFC6838 does not incorporate text/rust AFAICT.

Re: Should Emacs declare itself as being able to open all the text/* mimetypes?

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Other source code files might though. For example,
>>
>> $ xdg-mime query filetype src/js.rs 
>> text/rust
>
> RFC6838 does not incorporate text/rust AFAICT.

Indeed. That officially registered mimetype list in
https://www.iana.org/assignments/media-types/media-types.xhtml is rather
limited.

But xdg-mime is still recognizing a number of other types, including
text/x-makefile, which is also not on IANA list.

So, the idea of using the same mimetype for all OSes will not work.
"Standard" it too limited to rely on.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Björn Bidar <bjorn.bidar@thaodan.de>, eliz@gnu.org,
>  stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Tue, 19 Sep 2023 13:06:57 +0000
> 
> I agree that it is not difficult. But it is very easy to miss
> implementing a new scheme on _all_ the supported OSes. For example, I
> have no idea if Emacs even provides something similar to .desktop file
> on MacOS and Windows.

The "Open With" feature of the file managers on MS-Windows is not
determined by files like the XDG *.desktop files, it is determined by
system-wide "file-associations" that are modified by special commands
and/or settings offered by relevant applications.  (The associations
themselves are recorded in the Registry, of course.)  Emacs on
MS-Windows can thereafter make use of these associations via the
w32-shell-execute primitive.

So I don't see how we could offer something like that for Windows; we
learned long ago that including scripts or programs that write into
the Registry is a two-edged sword, so we refrain from doing that
nowadays.

> I mostly thought about file type handling.
> Wouldn't it be nice to allow built-in major modes also make Emacs
> register as application capable to open the corresponding file
> type/extension.

Most of this setup is not in Emacs at all, it is in the OS outside
Emacs and in other applications.  At least on MS-Windows.

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> ...
> So I don't see how we could offer something like that for Windows; we
> learned long ago that including scripts or programs that write into
> the Registry is a two-edged sword, so we refrain from doing that
> nowadays.

I see. Is it the same problem on MacOS?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
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>

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, bjorn.bidar@thaodan.de, stefankangas@gmail.com,
>  emacs-devel@gnu.org
> Date: Tue, 19 Sep 2023 13:56:23 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > ...
> > So I don't see how we could offer something like that for Windows; we
> > learned long ago that including scripts or programs that write into
> > the Registry is a two-edged sword, so we refrain from doing that
> > nowadays.
> 
> I see. Is it the same problem on MacOS?

I don't know about macOS, sorry.  Hopefully, someone else will chime
in and answer your question.

Re: Generic Elisp mechanism to declare file/URI handlers for Emacs (was: bug#65469: [PATCH] * etc/emacsclient.desktop: Make Emacs default application for org-protocol)

[Jim Porter]

On 9/19/2023 4:14 AM, Ihor Radchenko wrote:
> Would it make sense to create a more generic mechanism to collect a list
> of handlers from all the Elisp sources in Emacs and then generate
> Linux/Android/etc-specific definitions automatically when Emacs is
> compiled?
> 
> I imagine something akin how ;;;###autoload works - Elisp libraries that
> implement handling of certain file types or URI protocols declare this
> fact and then Emacs automatically pick this info, generating .desktop
> files and relevant parts of Andoid
> (java/org/gnu/emacs/EmacsOpenActivity.java) and whatever else necessary.

Yes please. Based on your imaginings, I'm in turn imagining something 
where I can type "emacs protocol://foo.bar" into my shell, and if I've 
enabled Emacs' handling for "protocol:" URLs somehow, this would now do 
some "protocol"-specific magic. (For org-protocol, that would be to 
start an Org capture or something; for mailto, that would be to compose 
a new message; etc.)

This would neatly resolve bug#65902 without having to mess around with 
emacsclient or the Emacs server protocol, and would hopefully let us 
remove the 'server-visit-files' advice in org-protocol. I'm sure there 
would be other interesting things we could do with an easy way of 
specifying URL handlers too (IRC links, HTTP(S) for EWW[1], etc).

[1] Probably not as the system-wide default, but "emacs 
https://example.com" could work.