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
> mailca
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 configu
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 `mailcap-m
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 &optional in-emacs line
search)
(when (eq cmd 'mailcap)
(require 'mailcap)
Ihor,
Your patch may be an improvement, but it requires an additional fix, see
below.
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
in
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 Nikulin
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 t
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 t
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 op
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:
application/x-shellsc
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 `mailcap-
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 of
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 outpu
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 you
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 the
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
(mailc
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, sinc
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 o
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 27.
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 not-too-dista
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 that
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.
mailc
[ 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. /home/user/myscr
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 org-file-ap
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.
36 matches
Mail list logo
