Re: [DISCUSSION, default settings] Using mailcap as default handler for opening file links

[Max Nikulin <manikulin@gmail.com>]

Ihor,

To be clear, I am not against taking into account XDG media types 
associations. I just believe that emacs settings should have higher 
priorities. Another point is that xdg-open is not intelligent enough to 
be used unconditionally.

I have the following idea. If (mailcap-mime-info mime-type) returns a 
function then it is used to open the file. If it is a string (shell 
command) then depending on some user option and DISPLAY, WAYLAND_DISPLAY 
environment variables either xdg-open or mailcap shell command is executed.

Notice the following issue:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972
Move `org-open-file' and associated code out of Org mode

Several issues with running external handlers are highlighted in 
comments. The changes were committed before I discovered history of code 
around xdg-open in browse-url.el. It is unclear to me what Eli had in mind.

If some XDG-related code appears in Org then likely it will be demand to 
have it in Emacs core (dired already has some kludge). However my 
experience of communication with Emacs developers is not encouraging.

A side note. On Debian there is the "open" command that may be 
configured to either xdg-open or run-mailcap through alternatives.

Some notes are inline.

On 14/02/2024 21:51, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> May you please explain more about this?
> What happens if a mailcap entry, say, declares "less" as a mimetype
> handler and Emacs is running in terminal?

An entry for "less" likely has terminal requirement in the "test" field 
and likely will be discarded by mailcap.el (I have not checked it).

> Also, I tried to run xdg-open from terminal (not emulator - C-M-<F1> on
> Linux) and it runs w3m for .png image vs. feh when running from terminal
> emulator on X.

xdg-open has a fallback to some hardcoded list of browsers. It is far 
from mailcap configuration. It does not use "see" and similar 
mailcap-related tools.

> So, I'd say that ordinary Emacs user probably has no idea that Emacs
> consults .mailcap to open /files/. Maybe some users (who are already
> familiar with .mailcap) expect .mailcap to be consulted when opening
> email attachments. But I am not sure - even reading
> https://man.archlinux.org/man/mailcap.5.en I cannot easily see why this
> would be used to open files; not to render them inline.

Users of mutt/pine/alpine have more chances to be familiar with mailcap.
Debian's version
https://manpages.debian.org/bookworm/mailcap/mailcap.5.en.html
is linked to more informative
https://manpages.debian.org/bookworm/mailcap/mailcap.order.5.en.html
https://manpages.debian.org/bookworm/mailcap/update-mime.8.en.html
though these tools are specific to Debian.

> I feel that we are abusing the scope of mailcap when opening file links.

 From my point of view, Org just uses facility that Emacs provides.

>> - Eli had objections, but did not provide any details.
>> - Error handling code was dropped for the sake of Emacs-25.
>> - In the case of no DE, quit from emacs means terminating of started
>> applications.
>> - I hope a bug I faced is exotic enough to never happen in real life.
> 
> Sorry, but I have no idea what you are talking about. I assume that it
> is some kind of Emacs bug you reported some time ago. I am not sure
> which one. And I do not see how it is related to this discussion.

See the link above.

>> Ideally Emacs should provide API that uses either xdg.el or mailcap.el
>> as backend depending on runtime and user configuration. Org is not the
>> only package that needs it.
> 
> Yes. But that's a lot of work; adding support of libmagic being just the
> first step. Implementing something more reasonable for Org mode only is
> a lower-handing fruit.

There are two orthogonal XDG specs:
- Lookup for a handler when media type is known
- Database of media types with file suffixes and signatures (magic 
sequences)

The former one is more important, unfortunately its implementation in 
Emacs has not nearly completed.