Re: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps

[Max Nikulin]

On 30/05/2022 21:00, Ihor Radchenko wrote:
> -      (let* ((mime-type (mailcap-extension-to-mime (or ext "")))
> +      (let* ((mime-type (if (executable-find "file")
> +                            (shell-command-to-string
> +                             (format "%s --brief --mime-type --dereference %s"
> +                                     (executable-find "file")

    (shell-quote-argument (executable-find "file"))

For the case of a directory with spaces or other characters interpreted 
by shell in the PATH environment.

Unsure if "file" command variants exist that do not support 
--dereference. Another pitfalls with `shell-command-to-string' is that 
it provides no way to handle errors. I would consider 2>/dev/null to not 
consider error message as MIME type and `mailcap-extension-to-mime' as 
fallback when "file" command fails.

(let* ((file-executable (executable-find "file"))
       (mime-type-file
        (and file-executable
         (shell-command-to-string
          (format "%s --brief --mime-type --dereference %s 2>/dev/null"
                 ; ...
        )))
       (mime-type (if (org-string-nw-p mime-type-file)
                      mime-type-file
                    (mailcap-extension-to-mime (or ext "")))

> +                                     (shell-quote-argument 
> (convert-standard-filename file))))
> +                          (mailcap-extension-to-mime (or ext ""))))

> Max Nikulin writes:
>
> > 3. With your patch and the following additional entry in ~/.mailcap
> >      (notice "text" instead of "application" and just "emacs")
> >          text/x-shellscript; emacs %s; test=test -n "$DISPLAY"
> >      new Emacs session is started. It is a problem but partially
> >      it is caused by incorrect mailcap configuration.
> >      Unlike "text/plain" that would be handled by view-mode
> >      unless `mailcap-mime-data' were erased in Emacs-27,
> >      "text/x-shellscript" is handled by less on my main system
> >      due to mailcap while I would expect same Emacs session.
>
> 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.)

I have not tried emacs-28 yet or some other full fledged desktop 
environment (in VM).

There is no official MIME type for shell scripts
http://www.iana.org/assignments/media-types/media-types.xhtml
so definitions "text" or "application", "x-sh" or "x-shellscript" vary. 
E.g. https://wiki.debian.org/ShellScript :
"The MIME type of shell scripts is nowadays text/x-shellscript but other 
systems may still use application/x-shellscript."

Emacs uses application/x-sh for the .sh suffix. There is no association 
for this type in `mailcap-mime-data'. The "file" command reports 
"text/x-shellscript". I have neither "application/x-sh" nor 
"text/x-shellscript" in /etc/mailcap (Ubuntu-20.04), there are only 
several entries for "application/x-shellscript". That is why your patch 
should not make handling of shell scripts worse... till mailcap and 
"file" will start to use the same type.

> > In some cases
> > it may be handy to launch remote viewer from a host accessed through
> > ssh, but let's leave it aside.
>
> This is exactly why you can always customize org-file-apps.

I am confused by this phrase. `org-file-apps' is ignored for remote 
files, otherwise more care would be required for executing "file".

> I added the extra argument as you suggested. See the new version of the
> patch. Though my man tells me that --dereference is the default. Not on
> your system apparently.

I have no idea. Quick search have not provided a changelog, but I have 
noticed https://bugs.astron.com/view.php?id=29

> > (mailcap-extension-to-mime "sh") => "text/x-sh"
> >
> > run-mailcap --norun examples/org/script/tstorg.sh
> > Error: no "view" mailcap rules found for type "application/x-sh"
> >
> > And "text/x-shellscript" as above.
>
> This should not matter for us. As long as mailcap-mime-info returns
> something meaningful, we should be good to go. Unless mailcap-mime-info
> itself is buggy.

Following a link to a shell script from an org file (without 
customization) I expect that it is opened in the same Emacs session. 
Maybe my expectation is wrong and system-wide handler (gedit, kate, 
etc.) should be launched. It seems current status quo (at least for some 
linux distributions) is consistent with my expectations, but only due to 
inconsistency in naming of the MIME type.