[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v2] Re: Bug in 9.5.3 org--file-default-apps
From: |
Ihor Radchenko |
Subject: |
[PATCH v2] Re: Bug in 9.5.3 org--file-default-apps |
Date: |
Thu, 26 May 2022 12:23:51 +0800 |
Max Nikulin <manikulin@gmail.com> writes:
> On 22/05/2022 11:10, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> The source of the problem is that Emacs-27 was released with the
>>> following bug:
>>>
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40247
>>> mailcap-mime-data erased when parsing mime parts
>>>
>>> So `mailcap-parse-mailcaps' called from `mailcap-mime-info' erases
>>> predefined associations in Emacs-27.
>>
>> If I understand correctly, this extra complication does not affect most
>> of the systems. I am not sure if we need to work around it.
>
> I would say that view-mode is quite reasonable default to open a
> "text/plain" file and this bug broke it.
I agree. However, I am already a bit lost with all the complications.
This particular one does not appear to be directly relevant to the
initial problem with a file with no extension. I'd prefer if this
Emacs-27 issue were reported in a separate thread.
>> Also, I am attaching a patch to address the original issue. We can just
>> use file command when available. WDYT?
>
> Ihor, have you manged to reproduce the original issue? Are links with
> explicit .txt suffix [[file:file.txt]] affected by the same problem? My
> environments sometimes behave in a way unexpected to you and I have not
> setup any tool to quickly launch transient virtual machines with no fear
> to "broke" current state, so I have not tried to debug the reported
> issue in its original form.
>
> I may be excessively suspicious.
Yes, I have managed to reproduce the original issue. Kind of.
We have the following in org-open-file:
(when (eq cmd 'mailcap)
(require 'mailcap)
(mailcap-parse-mailcaps)
(let* ((mime-type (mailcap-extension-to-mime (or ext "")))
(command (mailcap-mime-info mime-type)))
(if (stringp command)
(setq cmd command)
(setq cmd 'emacs))))
with EXT being bound to file extension.
When file does not have an extension (the original issue),
(mailcap-extension-to-mime) returns nil.
Then, (mailcap-mime-info nil) returns the same result with
(mailcap-mime-info "text/plain"). It is hard-coded inside
mailcap-mime-info.
So, with the current default value of org-file-apps-gnu, files with no
extension always use mime handler assigned to "text/plain" mimetype.
In a way, it is not wrong - mailcap spec only considers file extension
and has undefined behavior for files with no extension.
However, it does not make sense from the user perspective. Hence, I am
suggesting this patch. =file= command (when available) is more powerful
and looks at the file contents, not just into its extension.
>> + (let* ((mime-type (if (executable-find "file")
>> + (shell-command-to-string
>> + (format "%s --brief --mime-type %s"
>> + (executable-find "file")
>> + file))
>
> I hate elisp API related to executing of external processes because it
> encourages proliferation of unsafe code. What if the linked file name
> has some peculiarities and characters interpreted by shell?
>
> See [[file:/tmp/`touch /tmp/hacked`/test][here]]
Thanks for the heads up! Updated version of the patch is attached.
> I can not say that I fully understand `org-open-file' code, so I am
> unsure if remote file name can appear here, e.g. /ssh:user@host:testfie
> or a file form an archive due to a relative link [[file:testfile]] from
> a remote .org file. When remote files are not an issue, it is safer to
> use functions that takes command arguments as a list of string, not the
> command as a ready to execute string. Unfortunately there is no helper
> returning a string and accepting a command as a list.
org-file-apps-gnu defaults to
((remote . emacs)
(system . mailcap)
(t . mailcap))
All the "remote" files (including /ssh) will be opened in emacs. We
should have no issue in this area.
>> + (mailcap-extension-to-mime (or ext ""))))
>> (command (mailcap-mime-info mime-type)))
>> (if (stringp command)
>> (setq cmd command)
>
> P.S. `org-open-file' already has some problems with handling of some
> file names:
>
> Maxim Nikulin to emacs-orgmode. greedy substitution in org-open-file.
> Wed, 20 Jan 2021 23:08:35 +0700.
> https://list.orgmode.org/ru9ki4$t5e$1@ciao.gmane.io
Agree. Though it is not directly related. Maybe you can bump that thread
and mark is as a bug report to be listed on
https://updates.orgmode.org/?
Best,
Ihor
>From 4aeff613c07d9025c5fc1f0b3851870a42d36869 Mon Sep 17 00:00:00 2001
Message-Id:
<4aeff613c07d9025c5fc1f0b3851870a42d36869.1653538199.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Sun, 22 May 2022 12:04:35 +0800
Subject: [PATCH v2] org-open-file: Use file command to determine mime type,
when available
* lisp/org.el (org-open-file): Prefer file command to determine file
type instead of relying on `mailcap-extension-to-mime'. Only fallback
to the latter when file command is not available on the system.
Fixes
https://list.orgmode.org/874k1n2hpv.fsf@localhost/T/#mcc10df4ea7937360671e6dea8061153dee518807
---
lisp/org.el | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lisp/org.el b/lisp/org.el
index d7da8efc4..45a179a8a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -7975,7 +7975,12 @@ (defun org-open-file (path &optional in-emacs line
search)
(when (eq cmd 'mailcap)
(require 'mailcap)
(mailcap-parse-mailcaps)
- (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 %s"
+ (executable-find "file")
+ (shell-quote-argument
(convert-standard-filename file))))
+ (mailcap-extension-to-mime (or ext ""))))
(command (mailcap-mime-info mime-type)))
(if (stringp command)
(setq cmd command)
--
2.35.1
- Re: Bug in 9.5.3 org--file-default-apps, (continued)
- Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/18
- Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/18
- Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/19
- Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/19
- Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/20
- Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/20
- Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/20
- Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/21
- [PATCH] Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/22
- Re: [PATCH] Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/22
- [PATCH v2] Re: Bug in 9.5.3 org--file-default-apps,
Ihor Radchenko <=
- Re: [PATCH v2] Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/29
- [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/30
- Re: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/30
- Re: [PATCH v3] Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/31
- Re: [PATCH v2] Re: Bug in 9.5.3 org--file-default-apps, Max Nikulin, 2022/05/29
- Re: Bug in 9.5.3 org--file-default-apps, Craig STCR, 2022/05/23
- Re: Bug in 9.5.3 org--file-default-apps, Craig STCR, 2022/05/23
- Re: Bug in 9.5.3 org--file-default-apps, Craig STCR, 2022/05/23
- Re: Bug in 9.5.3 org--file-default-apps, Craig STCR, 2022/05/23
- Re: Bug in 9.5.3 org--file-default-apps, Ihor Radchenko, 2022/05/25