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

[Ihor Radchenko <yantar92@posteo.net>]

Max Nikulin <manikulin@gmail.com> writes:

> On 13/02/2024 18:27, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>> I am mostly going to address user confusion about mailcap
>
> XDG configuration and so xdg-open behavior is often confusing to users 
> as well, especially in the cases of KDE and no DE. In GNOME it is 
> alleviated by a step with the application chooser if default application 
> has not been set yet.

I'd say that it is less confusing.
Of course, if you know anything even less confusing than xdg-open,
please share.

>> (2) Emacs' mailcap does not implement the specification fully - only a
>> subset of mailcap format is obeyed.
>
> Agree. On the other hand, mailcap.el is aware that Emacs can handle some 
> files internally. This feature should be preserved in some way. In 
> addition, mailcap has to be used if neither DISPLAY nor WAYLAND_DISPLAY 
> is set for current terminal.

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?

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-mime is more close to the file(1) tool
>> 
>> That might be a good alternative to file indeed; although file is
>> probably more widely installed.
>
> xdg-mime and xdg-open belong to the same package. In the case of no DE 
> xdg-mime calls file(1) (if mimetype(1) is not installed).

So, we can try xdg-mime and fall back to file.

>> Yes, but mailcap is not documented in Emacs manual.
>
> (info "emacs-mailcap") However it is not as useful as it should be.

It is not expected to be read by Emacs users:

       This manual is directed at users who want to modify the behaviour of
    the MIME encoding/decoding process or want a more detailed picture of
    how the Emacs MIME library works, and people who want to write functions
    and commands that manipulate MIME elements.

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.

>>> Is it necessary to modify Org? Maybe an alternative is to add "xdg-open
>>> %s" for */* to `mailcap-user-mime-data'.
>> 
>> Do you mean changing the default value of `mailcap-mime-data'?
>
> I am unsure what is a proper way to do it. I am not confident enough 
> with the code that selects handlers for files.

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

>>> I am still not really comfortable due to the strategy to start external
>>> processes diverged from methods used in browse-url.el.
>> 
>> Is it related to the problem at hand?
>
> - 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.
>
> Unfortunately another approach is a kind of trade-off, not an 
> unambiguous advantage.

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.

>> AFAIK, xdg.el does not support xdg-open functionality. We cannot use it
>> here.
>
> `xdg-mime-apps' looks like a building block. However it is not enough 
> and perhaps has enough bugs.
>
> 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.

> P.S.
> Ihor, perhaps your clock is several minutes ahead.

I know.

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