hi, Ihor,
> It appears that using mailcap is giving us more trouble than benefits.
> I am not sure about the situation on Windows and Mac though.
> Should we change the default file handlers to Emacs globally (unless
> user customizes otherwise)? Should we continue efforts to work around
>
Max Nikulin writes:
>> 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
On 30/05/2022 22:38, Max Nikulin wrote:
(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"
; ...
)))
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"
Max Nikulin writes:
> However, in my opinion, it does not address original Craig's issue. The
> patch improves handling of *non-text* files requiring *external*
> viewers, while Craig complained that behavior for shell script is
> incorrect and his problem is tightly bound to erased
On 26/05/2022 11:23, Ihor Radchenko wrote:
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 in-emacs line
search)
(when (eq cmd 'mailcap)
(require 'mailcap)
ed there as
"org-open-file & org-file-apps multiple substitution bug"
but my point was that great care is required otherwise a lot of issues
may happen with shell command.
Ihor Radchenko. Bug in 9.5.3 org--file-default-apps.
Wed, 25 May 2022 14:18:10 +0800.
https://list.orgmode.org/87
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
>>>
Yeah I was wondering about that 'test' line. I was wondering if, like
you say, it gets ignored. Or if the true / false value gets passed to
some other logic that would, for example, add a '-nw' to the emacs
command line. I have no idea.
On 5/25/22 2:24 AM, Ihor Radchenko wrote:
Max
Max Nikulin writes:
>> application/x-shellscript; emacs27 %s; test=test -n "$DISPLAY"
>
> Notice that such entry will be ignored when DISPLAY is not set due to
> specified "test" property. You need to pass X socket and pass or set
> DISPLAY environment to you "headless" container.
Also, note
Craig STCR writes:
> '>$ run-mailcap myscript'
One comment. I do not personally have run-mailcap command on my system,
but searching for its docstring reveals
(http://www.linux-commands-examples.com/run-mailcap):
>> If the mime-type is omitted, an attempt to determine the type is
>> made by
Craig STCR writes:
> On 5/20/22 9:44 PM, Ihor Radchenko wrote:
>> However, I am not sure what to do on Windows/Mac.
> Maybe try a quick-and-dirty, cross-platform solution that checks
> non-binary files for a first-line shebang? Could use existing Emacs
> hooks that determine major-mode when
Craig, discussing the issue with Ihor, I sent some messages to the mail
list only without your address in Cc. You may check complete thread at
https://list.orgmode.org
On 23/05/2022 19:40, Craig STCR wrote:
OK, I did a first-try on this and was unsuccessful, but I'm sure it's
user error. I
On 5/23/22 10:14 AM, Craig STCR wrote:
>$ run-mailcap myscript
it invokes emacs. Yay! It works!
Double DOH! Forget what I said. It invokes vim, lol. That *is* what I
would expect. Sorry for the noise. I need to think a little more
before I hit .
Everything I mentioned so far has been my Bionic desktop. Which,
incidentally was an upgrade from Xenial, not a clean install. But... in
my Focal headless container, if I run:
>$ run-mailcap myscript
it invokes emacs. Yay! It works! DISPLAY, EDITOR, and VISUAL are all
unset or empty.
I guess maybe I should have given a little better description of what I
tried that did NOT work? But it's a little off-topic for this mailing
list. Nevertheless, here it is...
I created a ~/.mailcap file and put this in it, which I cut and pasted
from /etc/mailcap:
Thanks all for your help!
On 5/20/22 9:44 PM, Ihor Radchenko wrote:
Dear Craig, ... or provide plain/text handler in ~/.mailcap.
OK, I did a first-try on this and was unsuccessful, but I'm sure it's
user error. I need to refresh my knowledge on how to customize
user-local mime database, and
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
Max Nikulin writes:
> On 21/05/2022 08:44, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> It is the same with and without -Q and no, I have not customized
>>> `mailcap-user-mime-data', its value is nil, easy customization interface
>>> tells that it is the standard value. There is a chance
On 21/05/2022 08:44, Ihor Radchenko wrote:
Max Nikulin writes:
It is the same with and without -Q and no, I have not customized
`mailcap-user-mime-data', its value is nil, easy customization interface
tells that it is the standard value. There is a chance that debian has
some patch, but most
Max Nikulin writes:
> On 20/05/2022 15:22, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
> run-mailcap --norun ~/path/to/script
Note that mailcap.el does _not_ use run-mailcap or anything external. It
is written purely in elisp.
So, can you please report the
On 20/05/2022 15:22, Ihor Radchenko wrote:
Max Nikulin writes:
run-mailcap --norun ~/path/to/script
Note that mailcap.el does _not_ use run-mailcap or anything external. It
is written purely in elisp.
So, can you please report the output of M-: (mailcap-mime-info nil)?
view-mode
Sorry,
Max Nikulin writes:
>>> run-mailcap --norun ~/path/to/script
>>
>> Note that mailcap.el does _not_ use run-mailcap or anything external. It
>> is written purely in elisp.
>>
>> So, can you please report the output of M-: (mailcap-mime-info nil)?
>
> view-mode
Sorry, I did not consider that
On 19/05/2022 20:39, Ihor Radchenko wrote:
Max Nikulin writes:
On 18/05/2022 18:36, Ihor Radchenko wrote:
The behaviour is dependent on the OS-level mailcap defaults. What does
(mailcap-mime-info nil) return for you?
view-mode
^
run-mailcap --norun ~/path/to/script
Note that
Max Nikulin writes:
> On 18/05/2022 18:36, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> Sounds reasonable. However I just have tried a [[file:~/path/to/script]]
>>> link running Org main HEAD and the file is opened in emacs (26.3) other
>>> window.
>>
>> The behaviour is dependent on
On 18/05/2022 18:36, Ihor Radchenko wrote:
Max Nikulin writes:
Sounds reasonable. However I just have tried a [[file:~/path/to/script]]
link running Org main HEAD and the file is opened in emacs (26.3) other
window.
The behaviour is dependent on the OS-level mailcap defaults. What does
Craig STCR writes:
> I know your time is valuable. No need for you to spend a lot of time on
> this if I am the only one having this problem. It could be some random
> artifact in my installation, maybe something in my ~/.emacs. My
> ~/.emacs has a lot in it. And I have a work-around,
Max Nikulin writes:
> On 16/05/2022 18:57, Ihor Radchenko wrote:
>> Craig STCR writes:
>>> But with the new form in 9.5.3, /home/user/myscript is opened by
>>> /bin/less, not emacs. I assume mailcap is not consulted. Which does
>>> not work well. These behaviors are only for org. Outside of
On 17/05/2022 02:29, Craig STCR wrote:
On 5/16/22 11:14 AM, Max Nikulin wrote:
Sounds reasonable. However I just have tried a
[[file:~/path/to/script]] link running Org main HEAD and the file is
opened in emacs (26.3) other window.
Hmmm. That's interesting. I upgraded from Emacs 26.x to
On 5/16/22 11:14 AM, Max Nikulin wrote:
Sounds reasonable. However I just have tried a
[[file:~/path/to/script]] link running Org main HEAD and the file is
opened in emacs (26.3) other window.
Hmmm. That's interesting. I upgraded from Emacs 26.x to 27.x at some
point in the
On 5/16/22 11:14 AM, Max Nikulin wrote:
However I just have tried a [[file:~/path/to/script]] link running Org
main HEAD and the file is opened in emacs (26.3) other window.
Hmmm. That's interesting. I upgraded from Emacs 26.x to 27.x at some
point in the not-too-distant past. Maybe
On 16/05/2022 18:57, Ihor Radchenko wrote:
Craig STCR writes:
But with the new form in 9.5.3, /home/user/myscript is opened by
/bin/less, not emacs. I assume mailcap is not consulted. Which does
not work well. These behaviors are only for org. Outside of org, emacs
behaves correctly.
[ With 'Reply All' ]
Here's a summary of what I currently observe:
1) I was mistaken about the change from 9.5.2 to 9.5.3. You are
correct. As you noted, the 9.5.2, 9.5.3 diff I previously mentioned was
erroneous.
2) The problem I encounter with both 9.5.2 and 9.5.3 is that when
opening
Craig STCR writes:
> OK, I'll take a look as you suggested as soon as I can.
>
> So the form in 9.5.2 was a bug?
Yes, 9.5.2 version of that function was a bug.
> The problem I encounter with the new form in 9.5.3 is that when opening
> a shell script -- no file extension, e.g.
Craig STCR writes:
> 9.5.3 does not return org-file-apps-gnu because org-file-apps-gnu is not
> quoted. Should be (and was in 9.5.2):
>
> 'org-file-apps-gnu
>
> but in 9.5.3 it is:
>
> _ org-file-apps-gnu
Please try to run the following form:
(pcase 'gnu/linux
(`darwin
Craig STCR writes:
> I believe a change to the last line of org--file-default-apps introduced
> in 9.5.3 is a bug. For example, the change prevents shell scripts from
> being recognized correctly, since the mailcap logic in org-file-apps-gnu
> is no longer included in org--file-default-apps.
I believe a change to the last line of org--file-default-apps introduced
in 9.5.3 is a bug. For example, the change prevents shell scripts from
being recognized correctly, since the mailcap logic in org-file-apps-gnu
is no longer included in org--file-default-apps.
Best wishes,
-Craig Stcr1
37 matches
Mail list logo
