Max Nikulin <maniku...@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
