[DISCUSSION, default settings] Using mailcap as default handler for opening file links (was: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps)

[Ihor Radchenko <yantar92@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

>> I am confused here. org-file-apps-gnu says that we rely on mailcap:
>> 
>> ((remote . emacs)
>>   (system . mailcap)
>>   (t . mailcap))
>> 
>> So, is (3) following what you would expect from mailcap (regardless
>> whether it is incorrectly configured or not)? Wrong configuration of
>> mailcap is none of Org business - we need not to be "smart" and fix user
>> "errors". They may be deliberate.
>
> Ihor, I am afraid that your patch may break some subtle equilibrium 
> existing despite discrepancy in MIME type names for shell script. Worst 
> scenario: without the patch shell scripts are opened in the same Emacs 
> session, with it attempt to open a script silently fails due to "less" 
> handler requiring a terminal.
>
> I admit that your patch may improve handling of e.g. images, however it 
> is more rare case when an image file has no suffix, while it is quite 
> common for various scripts (shell, python, perl, etc.)

As Craig found out, Org 9.5.2 didn't try to use mailcap at all (because
of typo). So, the equilibrium you are talking about only exists since
Org 9.5.3 (April, 2022).

Before Org 9.5.3, the default behavior on Linux (not Windows or Mac) was
opening links in Emacs

or, more precisely
(funcall (cdr (assq 'file org-link-frame-setup)) file)

Since Org 9.5.3, the default behavior on Linux is using mailcap with all
the side-effects we are observing.

It appears that using mailcap is giving us more trouble than benefits.
I am not sure about the situation on Windows and Mac though.

Should we change the default file handlers to Emacs globally (unless
user customizes otherwise)? Should we continue efforts to work around
mailcap issues? Maybe there is yet another alternative generic way to
open files?

Best,
Ihor