From: Maxim Nikulin <email@example.com>
Cc: Lars Ingebrigtsen <firstname.lastname@example.org>, email@example.com
Subject: Re: bug#12972: 24.3.50; Move `org-open-file' and associated code out of Org mode
Date: Wed, 2 Jun 2021 23:20:50 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 01/06/2021 13:56, Lars Ingebrigtsen wrote:
> So I've now added this to Emacs 28 under the name
I am sorry if it is a false alarm. Feel free to close the bug again if
something changed recently in `start-process-shell-command' or if you
prefer to discuss the issue as another bug.
It seems that implementation of `mailcap-view-file' is unreliable due to
creation of unnecessary terminal session and it can cause obscure and
difficult to reproduce failures similar to
The thread is actually longer than it is shown in the archive interface.
Another lengthy discussion:
In Org latest change was required for compatibility reason:
Let-bind (process-connection-type nil) is a minimal required change to
avoid unnecessary terminal session. However it is not friendly to users
in the case when troubleshooting is required. `make-process' with
sentinel is hopefully better.
The following could be ignored since it likely requires significant
amount of work with unclear benefits.
1. `org-open-file' besides Org-specific stuff allows to specify precise
target inside the file. It can be quite useful, e.g.
okular --page 11 --find "some pattern" file.pdf
PDF files have internal anchors as well. I have no consistent vision how
to express additional "locators" in general API.
2. There are at least two sources of truth for MIME-handlers on linux
desktop that are not necessary synchronized. Info from extracted from
.desktop files may be configurable from desktop UI unlike mailcap.
Distros may have some instruments to mitigate discrepancies. Debian adds
entries from .desktop handlers to system-wide mailcap DB. Another
approach is to add to maicap greedy xdg-open handler that tries to guess
currently running desktop and pass arguments to appropriate command.
Maybe mailcap should be secondary MIME database in Emacs, not the
3. Currently only file suffix is inspected to determine MIME type of a
file. libmagic (or file command) usually provides more precise info, so
it is possible to open an incorrectly named file.
4. Mailcap has more features that are not addressed in Emacs. They may
be handy if Emacs is launched in terminal on remote server. It might
allow e.g. to open PDF file using pdftotext handler.
- A buffer for command output should be created for "copiousoutput" option.
- A buffer should be created and terminal session should be enabled if
an entry "needsterminal".
- There are more substitutions than "%s". However I am unsure if it is
possible to provide more info than application can obtain from the file.
I think, it is intended for mail multipart messages and additional headers.
On the other hand mailcap handlers might expect safe file names (minimal
ASCII subset), users may have files with arbitrary names (national
charset or some special characters). I hope, almost all handlers do not
have such problem.
In summary, during launch of external command terminal session must be
suppressed. There is enough room for MIME-related improvements in Emacs
in general and in Org mode in particular.
next prev parent reply other threads:[~2021-06-02 16:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <F3C1A7E58B2441F7A674239043AC031A@us.oracle.com>
2021-06-01 6:56 ` bug#12972: 24.3.50; Move `org-open-file' and associated code out of Org mode Lars Ingebrigtsen
[not found] ` <email@example.com>
2021-06-02 16:20 ` Maxim Nikulin [this message]
2021-07-01 17:01 ` bug#12972: [PATCH] Avoid regression in mailcap-view-file similar to Bug#44824 Maxim Nikulin
2021-07-01 18:38 ` Eli Zaretskii
[not found] ` <firstname.lastname@example.org>
2021-07-02 12:21 ` Maxim Nikulin
2021-07-02 12:37 ` Eli Zaretskii
[not found] ` <email@example.com>
2021-07-02 16:24 ` Maxim Nikulin
2021-07-02 17:28 ` Eli Zaretskii
[not found] ` <firstname.lastname@example.org>
2021-07-03 11:29 ` Maxim Nikulin
2021-07-03 11:56 ` Eli Zaretskii
[not found] ` <email@example.com>
2021-07-04 13:37 ` Maxim Nikulin
2021-07-04 13:49 ` Eli Zaretskii
2021-07-05 13:12 ` Maxim Nikulin
2021-07-05 15:23 ` Eli Zaretskii
2021-07-30 12:01 ` bug#12972: 24.3.50; Move `org-open-file' and associated code out of Org mode Lars Ingebrigtsen
2021-07-30 12:24 ` Maxim Nikulin
2021-07-30 12:42 ` Lars Ingebrigtsen
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).