[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Max Nikulin
Subject: Re: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps
Date: Mon, 30 May 2022 22:38:13 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

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"))
        (and file-executable
          (format "%s --brief --mime-type --dereference %s 2>/dev/null"
                 ; ...
       (mime-type (if (org-string-nw-p 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
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]