Max Nikulin 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