GNU bug report logs -
#18132
Time for a smarter dired-guess-shell-alist-default? (dired-x.el)
Previous Next
To reply to this bug, email your comments to 18132 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Mon, 28 Jul 2014 18:27:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Reuben Thomas <rrt <at> sc3d.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 28 Jul 2014 18:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
These days, there are mature programs for launching an arbitrary file with
an appropriate viewer: run-mailcap (which is mature to the point of
obsolescence) and xdg-open on GNU systems; open on Mac OS X; start on MS
Windows).
xdg-open already works reasonably well:
http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/msg00143.html
(I have a fix for the "multiple files" problem, which I'll be sending to
xdg-utils upstream when I can.)
Hence it would seem sensible to have a new default for
dired-guess-shell-alist-default, which matches any file and returns the
appropriate command for the OS, probably doing some testing to see which
commands are available on a GNU system ("xdg-open", "gvfs-open", "see"…).
The user then only needs to understand and configure one command-launching
system, and the coverage of different filetypes is much more comprehensive
in most such systems than in dired-x.el.
An advantage to Emacs is that this system could then be used elsewhere. For
example, org-mode already has a similar, separate system, org-file-apps,
which might benefit from building on dired-x, and only retaining its own
configuration where it's desirable to open a file "internally" to org-mode.
--
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Mon, 28 Jul 2014 18:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Xah Lee has already written some code to do this:
http://ergoemacs.org/emacs/emacs_dired_open_file_in_ext_apps.html
--
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Tue, 29 Jul 2014 23:53:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> These days, there are mature programs for launching an arbitrary file with
> an appropriate viewer: run-mailcap (which is mature to the point of
> obsolescence) and
run-mailcap is fully supported by shell-command and async-shell-command where
the list of available commands can be accessed using M-n in its minibuffer.
> xdg-open on GNU systems; open on Mac OS X; start on MS Windows).
xdg-open is a single command that is too easy to add to the top of this list.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 30 Jul 2014 03:57:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 28 Jul 2014 19:26:07 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
>
> These days, there are mature programs for launching an arbitrary file with
> an appropriate viewer: run-mailcap (which is mature to the point of
> obsolescence) and xdg-open on GNU systems; open on Mac OS X; start on MS
> Windows).
It would be a bad idea to use 'start' on Windows: it has too many
quirks regarding quoting of its command line. Instead, just invoke
the existing primitive w32-shell-execute with the 'open' verb. As a
nice side effect, this will support Unicode file names, something that
is currently impossible when you invoke an external command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 30 Jul 2014 09:13:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 30 July 2014 00:49, Juri Linkov <juri <at> jurta.org> wrote:
> > These days, there are mature programs for launching an arbitrary file
> with
> > an appropriate viewer: run-mailcap (which is mature to the point of
> > obsolescence) and
>
> run-mailcap is fully supported by shell-command and async-shell-command
> where
> the list of available commands can be accessed using M-n in its minibuffer.
>
I can't see any mention of run-mailcap in the Emacs source; do you mean
simply that it's possible to add it to the list of commands used?
> > xdg-open on GNU systems; open on Mac OS X; start on MS Windows).
>
> xdg-open is a single command that is too easy to add to the top of this
> list.
>
Did you mean "easy too"?
So, yes, both of these commands can be added.
My original point is that they're not currently used; instead there is a
custom list that has to be configured separately by the user from either of
these.
Hence, I suggest using these commands (and similarly "open" on Mac OS, and,
as per Eli's suggestion, w32-shell-execute on Windows) instead of the
current contents of dired-guess-shell-alist-default.
Since each of these commands tackles all file types, it would seem simplest
to add a new function shell-execute, modelled on w32-shell-execute, and
have dired-read-shell-command use that instead of
dired-guess-shell-command, which could then become an option that
shell-execute can be configured to use, for those who are used to it.
--
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 30 Jul 2014 16:38:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> run-mailcap is fully supported by shell-command and async-shell-command where
>> the list of available commands can be accessed using M-n in its minibuffer.
>
> I can't see any mention of run-mailcap in the Emacs source; do you mean
> simply that it's possible to add it to the list of commands used?
grep -nH mailcap *.el
./dired-aux.el:558:(declare-function mailcap-file-default-commands "mailcap" (files))
./dired-aux.el:562:This function is used to add all related commands retrieved by `mailcap'
./dired-aux.el:565: (let ((commands (and (boundp 'files) (require 'mailcap nil t)
./dired-aux.el:566: (mailcap-file-default-commands files))))
./simple.el:2743:(declare-function mailcap-file-default-commands "mailcap" (files))
./simple.el:2748:This function is used to add all related commands retrieved by `mailcap'
./simple.el:2754: (commands (and filename (require 'mailcap nil t)
./simple.el:2755: (mailcap-file-default-commands (list filename)))))
> My original point is that they're not currently used; instead there is a
> custom list that has to be configured separately by the user from either of
> these.
We could leave the original list intact, and add xdg-open/w32-shell-execute
to the top of the list, so it would be the first suggestion that the user
will get after the first M-n.
There is a good example how to check its availability in
`browse-url-can-use-xdg-open' that could be moved
to a more general file like simple.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 30 Jul 2014 16:45:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 30 July 2014 17:32, Juri Linkov <juri <at> jurta.org> wrote:
> >> run-mailcap is fully supported by shell-command and async-shell-command
> where
> >> the list of available commands can be accessed using M-n in its
> minibuffer.
> >
> > I can't see any mention of run-mailcap in the Emacs source; do you mean
> > simply that it's possible to add it to the list of commands used?
>
> grep -nH mailcap *.el
> ./dired-aux.el:558:(declare-function mailcap-file-default-commands
> "mailcap" (files))
> ./dired-aux.el:562:This function is used to add all related commands
> retrieved by `mailcap'
> ./dired-aux.el:565: (let ((commands (and (boundp 'files) (require
> 'mailcap nil t)
> ./dired-aux.el:566: (mailcap-file-default-commands
> files))))
> ./simple.el:2743:(declare-function mailcap-file-default-commands "mailcap"
> (files))
> ./simple.el:2748:This function is used to add all related commands
> retrieved by `mailcap'
> ./simple.el:2754: (commands (and filename (require 'mailcap nil t)
> ./simple.el:2755: (mailcap-file-default-commands
> (list filename)))))
>
I'm sorry if I've missed something, but I don't see what this has to do
with run-mailcap.
> We could leave the original list intact, and add xdg-open/w32-shell-execute
> to the top of the list, so it would be the first suggestion that the user
> will get after the first M-n.
>
It would be good to discourage customization of
dired-guess-shell-alist-{default,user}, and steer users towards the
non-program-specific mechanisms. It would also be good eventually not to
have to maintain the list, or indeed the dired-guess-shell mechanism at all.
As for your mention of "the first M-n", as far as I can discover, the first
time I press M-n, the default command, which was already mentioned in the
prompt, is simply inserted at point, as if I had typed it. So is "the first
suggestion that the user will get after the first M-n" actually the same
thing as "the default suggestion"? (I hope so!)
> There is a good example how to check its availability in
> `browse-url-can-use-xdg-open' that could be moved
> to a more general file like simple.el.
>
Thanks for the pointer.
--
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Tue, 05 Aug 2014 00:11:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> I'm sorry if I've missed something, but I don't see what this has to do
> with run-mailcap.
run-mailcap always runs the first alternative, but with
`mailcap-file-default-commands' you can select a command
to run using several M-n.
> It would be good to discourage customization of
> dired-guess-shell-alist-{default,user}, and steer users towards the
> non-program-specific mechanisms. It would also be good eventually not to
> have to maintain the list, or indeed the dired-guess-shell mechanism at all.
Instead of customization, a more useful UI would be to remember
the most frequently used commands, and provide them at the top
of the completions in the minibuffer.
> As for your mention of "the first M-n", as far as I can discover, the first
> time I press M-n, the default command, which was already mentioned in the
> prompt, is simply inserted at point, as if I had typed it. So is "the first
> suggestion that the user will get after the first M-n" actually the same
> thing as "the default suggestion"? (I hope so!)
Yes, this is so when the prompt displays the default value.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Tue, 05 Aug 2014 09:42:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 5 August 2014 00:45, Juri Linkov <juri <at> jurta.org> wrote:
> > I'm sorry if I've missed something, but I don't see what this has to do
> > with run-mailcap.
>
> run-mailcap always runs the first alternative, but with
> `mailcap-file-default-commands' you can select a command
> to run using several M-n.
>
> ...
>
> Instead of customization, a more useful UI would be to remember
> the most frequently used commands, and provide them at the top
> of the completions in the minibuffer.
>
Unfortunately, we seem to have strayed from my question, "can I replace
dired-guess-shell-* with a function that calls a suitable file-type
dispatcher (xdg-open, open, w32-shell-execute &c.)" to a discussion of
mailcap support, which is related, but perhaps better dealt with separately
(given that I'm talking about removing, not adding, functionality from
Emacs).
I was really trying to address two concerns:
1. Do other maintainers agree that it is sensible to remove Emacs's
duplicated mechanism for guessing which command to run on a given filetype,
and instead use a system mechanism (according to the underlying system)?
2. I assume that for reasons of backward compatibility it would not be
acceptable immediately to remove dired-guess-shell-*, hence my suggestion
to implement step 1 in the first instance by supplying a new default value
for dired-guess-shell-alist-default. If later this variable could be
deprecated and replaced with a simple function, so much the better.
--
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 05:26:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 18132 <at> debbugs.gnu.org (full text, mbox):
Reuben Thomas <rrt <at> sc3d.org> writes:
> Unfortunately, we seem to have strayed from my question, "can I
> replace dired-guess-shell-* with a function that calls a suitable
> file-type dispatcher (xdg-open, open, w32-shell-execute &c.)" to a
> discussion of mailcap support, which is related, but perhaps better
> dealt with separately (given that I'm talking about removing, not
> adding, functionality from Emacs).
>
> I was really trying to address two concerns:
>
> 1. Do other maintainers agree that it is sensible to remove Emacs's
> duplicated mechanism for guessing which command to run on a given
> filetype, and instead use a system mechanism (according to the
> underlying system)?
I agree, but I will add that it would be very nice if we don't lose the
capability of seeing which command will be run on a file when typing &
(dired-do-async-shell-command) on a file in Dired. It sucks when the
default only says "xdg-open", as you don't know what program that will
open or if it is indeed the one you want.
Does xdg-open have the capability to just print what it would run
without actually executing it? I can't see such a flag on Debian
stable/bookworm. If that is missing, should we perhaps add a feature
request for it?
https://www.freedesktop.org/wiki/Software/xdg-utils/
But in that case, we would need to check for that capability first,
somehow...
> 2. I assume that for reasons of backward compatibility it would not be
> acceptable immediately to remove dired-guess-shell-*, hence my
> suggestion to implement step 1 in the first instance by supplying a
> new default value for dired-guess-shell-alist-default. If later this
> variable could be deprecated and replaced with a simple function, so
> much the better.
Right, we can't just remove it outright.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 07:46:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Fri, 22 Oct 2021 22:25:09 -0700
> Cc: 18132 <at> debbugs.gnu.org
>
> Reuben Thomas <rrt <at> sc3d.org> writes:
>
> > 1. Do other maintainers agree that it is sensible to remove Emacs's
> > duplicated mechanism for guessing which command to run on a given
> > filetype, and instead use a system mechanism (according to the
> > underlying system)?
>
> I agree, but I will add that it would be very nice if we don't lose the
> capability of seeing which command will be run on a file when typing &
> (dired-do-async-shell-command) on a file in Dired. It sucks when the
> default only says "xdg-open", as you don't know what program that will
> open or if it is indeed the one you want.
It's not only that. Emacs's ability to run programs given a file can
extend and surpass those of the underlying OS, and the ability of
Emacs users to configure and customize that in a unified
system-independent manner are either better or simply not available at
all in the OS-level tools which offer similar functionality.
So I think it would be nice to extend dired-guess-shell-* so that it
could delegate to the OS-level capabilities like xdg-open or
w32-shell-execute, but we should preserve the abilities to override or
extend that with Emacs-level associations between files and programs.
> > 2. I assume that for reasons of backward compatibility it would not be
> > acceptable immediately to remove dired-guess-shell-*, hence my
> > suggestion to implement step 1 in the first instance by supplying a
> > new default value for dired-guess-shell-alist-default. If later this
> > variable could be deprecated and replaced with a simple function, so
> > much the better.
>
> Right, we can't just remove it outright.
I'm not sure I understand what exactly is proposed here as "step 1",
but it sounds like it's the same as my "extend dired-guess-shell-*"
proposal above? Then I agree, of course, I just think that we don't
need to do anything else, and in particular we should never remove the
ability of Emacs users to augment/extend/override those system-level
facilities.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 08:17:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 18132 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It's not only that. Emacs's ability to run programs given a file can
> extend and surpass those of the underlying OS, and the ability of
> Emacs users to configure and customize that in a unified
> system-independent manner are either better or simply not available at
> all in the OS-level tools which offer similar functionality.
>
> So I think it would be nice to extend dired-guess-shell-* so that it
> could delegate to the OS-level capabilities like xdg-open or
> w32-shell-execute, but we should preserve the abilities to override or
> extend that with Emacs-level associations between files and programs.
That sounds like exactly the right thing to do. So we need to add stuff
here, without taking anything away.
However, I will add that while we maintain our current capabilities for
customization, we might want to consider removing or updating some
entries from `dired-guess-shell-alist-default'. For example, we
currently recommend xpdf for PDF:s, which, sure, is presumably available
"everywhere", but also is pretty lacking in features and just plain
clunky compared to something like evince.
To make matters even worse,
emacs -Q --eval "(progn (require 'dired-x) (dired \"~\"))"
happily offers up xpdf as the default command for PDF:s even though I
don't even have xpdf installed! So perhaps it's not that ubiquitous
these days... you have to specifically install it to even have it.
Looking even more closely at this, I guess `xdg-open' could be used as
some final fallback, but it doesn't seem to add anything that isn't
already available from mailcap? And we already have
`mailcap-file-default-commands', so why not just provide a default based
on that?
On my machine, I get the very reasonable:
(mailcap-file-default-commands '("foo.pdf"))
=> ("evince" "xdg-open")
So why not just move the guessing stuff over to dired.el, re-base it on
mailcap, and minimize the list in `dired-guess-shell-alist-default' to
something more reasonable. Perhaps that list could be just nil by
default if we have the usual mailcap stuff?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 08:36:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sat, 23 Oct 2021 01:16:48 -0700
> Cc: rrt <at> sc3d.org, 18132 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > It's not only that. Emacs's ability to run programs given a file can
> > extend and surpass those of the underlying OS, and the ability of
> > Emacs users to configure and customize that in a unified
> > system-independent manner are either better or simply not available at
> > all in the OS-level tools which offer similar functionality.
> >
> > So I think it would be nice to extend dired-guess-shell-* so that it
> > could delegate to the OS-level capabilities like xdg-open or
> > w32-shell-execute, but we should preserve the abilities to override or
> > extend that with Emacs-level associations between files and programs.
>
> That sounds like exactly the right thing to do. So we need to add stuff
> here, without taking anything away.
Yes, that's the idea.
> However, I will add that while we maintain our current capabilities for
> customization, we might want to consider removing or updating some
> entries from `dired-guess-shell-alist-default'. For example, we
> currently recommend xpdf for PDF:s, which, sure, is presumably available
> "everywhere", but also is pretty lacking in features and just plain
> clunky compared to something like evince.
>
> To make matters even worse,
>
> emacs -Q --eval "(progn (require 'dired-x) (dired \"~\"))"
>
> happily offers up xpdf as the default command for PDF:s even though I
> don't even have xpdf installed! So perhaps it's not that ubiquitous
> these days... you have to specifically install it to even have it.
I think that's a separate issue: how to deal with a failure to invoke
the program which we guessed would be appropriate for the file in
question. I could argue that we should try invoking the program
anyway, because failure to invoke it could mean the user should
install some component, and that is useful information for the user.
> Looking even more closely at this, I guess `xdg-open' could be used as
> some final fallback, but it doesn't seem to add anything that isn't
> already available from mailcap? And we already have
> `mailcap-file-default-commands', so why not just provide a default based
> on that?
Because that's not portable enough?
> On my machine, I get the very reasonable:
>
> (mailcap-file-default-commands '("foo.pdf"))
> => ("evince" "xdg-open")
Here, the above returns something much less useful:
("pdftotext ? -" "gv -safer")
None of that would have helped me to view a PDF file.
So if we want to use mailcap for this, we'd need to extend that, and
make it smarter, in particular on non-GNU/Linux platforms.
More generally, I'm not sure mailcap is the right tool for the job:
its main purpose is to view attachments to email messages, where we
generally have metadata (MIME etc.) which is not necessarily available
for arbitrary disk files.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 09:49:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 18132 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> More generally, I'm not sure mailcap is the right tool for the job:
> its main purpose is to view attachments to email messages, where we
> generally have metadata (MIME etc.) which is not necessarily available
> for arbitrary disk files.
Isn't that just "file --mime-type -b"? file is a BSD command AFAICT so
it should presumably be available almost everywhere.
I also see in the man page than a certain Reuben Thomas has been
involved in its development so maybe he has something to add here. :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 11:49:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sat, 23 Oct 2021 02:48:19 -0700
> Cc: rrt <at> sc3d.org, 18132 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > More generally, I'm not sure mailcap is the right tool for the job:
> > its main purpose is to view attachments to email messages, where we
> > generally have metadata (MIME etc.) which is not necessarily available
> > for arbitrary disk files.
>
> Isn't that just "file --mime-type -b"? file is a BSD command AFAICT so
> it should presumably be available almost everywhere.
It isn't available on Windows, for starters. (I do have it, but I
ported it myself.)
And what about files that have no MIME type defined for them? Or
where 'file's output is not really useful, like this:
$ file --mime-type -b elisp.info
application/octet-stream
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 13:02:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 23 Oct 2021 at 09:16, Stefan Kangas <stefan <at> marxist.se> wrote:
>
> That sounds like exactly the right thing to do. So we need to add stuff
> here, without taking anything away.
>
That would be a shame: there are too many things in Emacs that just get
more complicated over time. I'm dubious about the utility of
system-independent configuration here too.
Looking even more closely at this, I guess `xdg-open' could be used as
> some final fallback, but it doesn't seem to add anything that isn't
> already available from mailcap?
xdg-open uses the underlying desktop system's MIME infrastructure. For a
GNU system, that would most typically be GNOME, and its "gio open" (or on
older systems, gvfs-open) command.
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 13:07:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 23 Oct 2021 at 10:48, Stefan Kangas <stefan <at> marxist.se> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > More generally, I'm not sure mailcap is the right tool for the job:
> > its main purpose is to view attachments to email messages, where we
> > generally have metadata (MIME etc.) which is not necessarily available
> > for arbitrary disk files.
>
> Isn't that just "file --mime-type -b"? file is a BSD command AFAICT so
> it should presumably be available almost everywhere.
>
> I also see in the man page than a certain Reuben Thomas has been
> involved in its development so maybe he has something to add here. :-)
>
I agree with Eli that mailcap is not the right tool for the job.
file's MIME-type support is easy to fix for types that don't (yet) have a
MIME type supplied; file is actively maintained and frequently released.
Note that xdg-open won't use file on a system that has its own MIME-type
handling, such as GNOME.
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 13:21:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Reuben Thomas <rrt <at> sc3d.org>
> Date: Sat, 23 Oct 2021 14:06:27 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 18132 <at> debbugs.gnu.org
>
> I agree with Eli that mailcap is not the right tool for the job.
(Then why are we still talking about 'file'?)
> file's MIME-type support is easy to fix for types that don't (yet) have a MIME type supplied; file is actively
> maintained and frequently released.
Not sure it will help. Example:
$ file --mime-type -k -b lisp/international/uni-bidi.el
application/octet-stream
Looks like there are some fundamental problems in 'file' that make it
not ideal for this purpose, to say the least. Which, to me, just
reiterates what I already said up-thread: we should allow users to
override what the system-level tools provide, because they will never
be 100% satisfactory for our needs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 13:58:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 18132 <at> debbugs.gnu.org (full text, mbox):
Reuben Thomas <rrt <at> sc3d.org> writes:
> xdg-open uses the underlying desktop system's MIME infrastructure. For a
> GNU system, that would most typically be GNOME, and its "gio open" (or on
> older systems, gvfs-open) command.
I don't see that shooting away blindly to xdg-open is satisfactory; the
user should be able to a) know which command is being run before running
it and b) modify it on the fly. Maybe I want to open PDF:s first with
one and then another PDF reader to see if it looks the same, just as I
would be able to from a graphical file manager.
Thus, the most important question to my mind is "how can we get the
default command for a file in the best way".
I think ideally we should get this from the system, optionally with
overrides and/or fallbacks from Emacs or the user. I don't particularly
care if it comes from mailcap, from /usr/share/applications, but we
should preferably pick the "best" one.
Eli says that portability is a concern with mailcap, which is true but
also not something we can't work around.
You say that mailcap is the wrong tool for the job. (Why?)
I claim that the `xdg-open' script does not seem to solve the problem.
Then I ask: what is the correct tool for the job of finding the command
to run?
Maybe we need try several different things? I see that `xdg-open' tries
all kinds of different things ("gio open", "gvfs open", "open_generic",
etc.). But our needs are different: we want the command as a string, we
don't just want to run it.
PS. For the sake of simplicity, I would suggest that we could first
figure out what to do on GNU/Linux and then we'll see if we can get
that solution to work elsewhere or if we need to get other things in
place.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 14:05:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 23 Oct 2021 at 14:57, Stefan Kangas <stefan <at> marxist.se> wrote:
> Maybe I want to open PDF:s first with
> one and then another PDF reader to see if it looks the same, just as I
> would be able to from a graphical file manager.
>
Then you won't be using the default command anyway.
You say that mailcap is the wrong tool for the job. (Why?)
>
I agree with Eli's reasoning.
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 15:46:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 18132 <at> debbugs.gnu.org (full text, mbox):
Reuben Thomas <rrt <at> sc3d.org> writes:
> On Sat, 23 Oct 2021 at 14:57, Stefan Kangas <stefan <at> marxist.se> wrote:
>
>> Maybe I want to open PDF:s first with
>> one and then another PDF reader to see if it looks the same, just as I
>> would be able to from a graphical file manager.
>>
>
> Then you won't be using the default command anyway.
What I want is more or less the exact behavior of xdg-open, but I want
to be able to check the actual command (e.g. "evince", not just
"xdg-open") before pressing RET.
I also want to be able to override xdg-open with customizations inside
Emacs.
> I agree with Eli's reasoning.
Please bare with me as I'm trying to understand.
Is your preference still to just run "xdg-open", as you explained in
your original bug report? (It was quite some time ago, which is why I'm
asking, in case your position has changed.)
Do you agree that if we could get my idea to work, you could have your
cake and eat it too? IOW, do you disagree with the approach because you
think it is infeasible to make it work well, or because you don't think
that the feature sounds useful? Or do you merely disagree with using
mailcap to implement it?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 17:18:02 GMT)
Full text and
rfc822 format available.
Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):
>
> What I want is more or less the exact behavior of xdg-open, but I want
> to be able to check the actual command (e.g. "evince", not just
> "xdg-open") before pressing RET.
>
xdg-mime query default $(xdg-mime query filetype FILE)
should return the name of one of the files /usr/share/applications, and
you can check for the line starting with Exec in that file to see what
command it launches.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 17:18:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 17:58:01 GMT)
Full text and
rfc822 format available.
Message #74 received at submit <at> debbugs.gnu.org (full text, mbox):
>> xdg-open uses the underlying desktop system's MIME infrastructure. For a
>> GNU system, that would most typically be GNOME, and its "gio open" (or on
>> older systems, gvfs-open) command.
>
> I don't see that shooting away blindly to xdg-open is satisfactory; the
> user should be able to a) know which command is being run before running
> it and b) modify it on the fly. Maybe I want to open PDF:s first with
> one and then another PDF reader to see if it looks the same, just as I
> would be able to from a graphical file manager.
In the spirit of "we need to add stuff here, without taking
anything away" can I suggest just adding a new dired-do-open
command that calls out to xdg-open on gnu/linux or open on
darwin or windows. Such a command has been written many
times and people add it to their local configs. I have it
bound on X in dired and use it far more often than I do M-!.
Such a command emulates what double clicking on an icon does
which most of the time is what a user wants (because it's
configured it do what their most common app need is).
Having emacs provide the command means it could be correct
reguarding shell quoting and other small issues that people
might get wrong on their own.
For those that want more control either in picking the
command that is run or seeing it beforehand, they can use
and configure dired-guess-shell-alist-default.
--
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 18:38:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> Such a command emulates what double clicking on an icon does
> which most of the time is what a user wants (because it's
> configured it do what their most common app need is).
Such a command is long overdue. I used the following command
for a long time, and forgot it's not in dired-x. I don't suggest
to use this implementation, but something like this. Then like
clicking the right mouse button on a file shows a list of
available apps to open the file in, and M-& does practically the same
with the keyboard. Then like double clicking on an icon,
some key should use the default command to open the file.
#+begin_src emacs-lisp
(define-key dired-mode-map [(control return)] 'my-dired-run-find-file)
(defun my-dired-run-find-file ()
"View file for dired."
(interactive)
(let* ((file (dired-get-filename)))
(cond
((let* ((command
(and (functionp 'mm-mime-info)
(mm-mime-info
(mm-extension-to-mime (file-name-extension file))))))
(if (and command (stringp command))
;; always return ‘t’ for ‘cond’
(or (ignore (async-shell-command (concat (format command file) "&")))
t))))
((string-match "\\.html?$" file)
(cond
((fboundp 'browse-url)
(browse-url file))))
((string-match "\\.elc?$" file)
(load-file file))
((string-match "\\.info?$" file)
(info file))
((let* ((file-list (list (dired-get-filename)))
(command (dired-guess-default file-list))
(async-shell-command-display-buffer nil))
(if (listp command)
(setq command (car command)))
(if command
(async-shell-command
(dired-shell-stuff-it command file-list nil 0)))))
(t
(message "%s" file)))))
#+end_src
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 19:23:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> Such a command is long overdue. I used the following command
> for a long time, and forgot it's not in dired-x. I don't suggest
> to use this implementation, but something like this.
Likewise. There are lots of similar possibilities.
These are what I use, for MS Windows. In Dired,
I have these bindings (plus mouse versions):
C-RET dired-w32explore
M-RET dired-w32-browser
C-M-RET dired-multiple-w32-browser
(defun dired-w32-browser ()
"Run default Windows application associated with current line's file.
If file is a directory, then `dired-find-file' instead.
If no application is associated with file, then `find-file'."
(interactive)
(let ((file (dired-get-filename nil t)))
(if (file-directory-p file)
(dired-find-file)
(w32-browser (subst-char-in-string ?/ ?\\ file)))))
(defun w32-browser (file)
"Run default Windows application associated with FILE.
If no associated application, then `find-file' FILE."
(interactive "fFile: ")
(or (condition-case nil
(w32-shell-execute nil file) ; Use Windows file association
(error nil))
(find-file file)))
(defun dired-w32explore ()
"Open Windows Explorer to current file or folder."
(interactive)
(w32explore (dired-get-filename nil t)))
(defun w32explore (file)
"Open Windows Explorer to FILE (a file or a folder)."
(interactive "fFile: ")
(let ((w32file (subst-char-in-string ?/ ?\\ (expand-file-name file))))
(if (file-directory-p w32file)
(w32-shell-execute "explore" w32file "/e,/select,")
(w32-shell-execute "open" "explorer" (concat "/e,/select," w32file)))))
(defun dired-multiple-w32-browser ()
"Run default Windows applications associated with marked files."
(interactive)
(let ((files (dired-get-marked-files)))
(while files
(w32-browser (car files))
(sleep-for w32-browser-wait-time)
(setq files (cdr files)))))
(defun dlgopen-open-files (&optional flip)
"Open files using the Windows standard Open dialog box.
Var `dlgopen-executable-path' is path of executable `getfile.exe'.
If `w32-browser' is defined, then it is used to open the selected
files. Otherwise, standard Emacs `find-file' functions are used.
If `w32-browser' is not defined, then `dlgopen-other-window'
controls how selected files are opened:
non-nil => Display chosen file(s) in separate windows.
nil => Display a single chosen file in the current window;
don't display multiple chosen files.
Optional prefix arg FLIP non-nil reverses the effect of variable
`dlgopen-other-window', for this call."
(interactive "P")
(unless (eq system-type 'windows-nt)
(error "Command `dlgopen-open-files' is for Windows only"))
(let ((buffer "")
(file-fqn "")
(lines-in-page 0)
(dir-path "")
(other-win (if flip
(not dlgopen-other-window)
dlgopen-other-window)))
(setq buffer (generate-new-buffer "files-to-open"))
(when (call-process dlgopen-executable-path nil buffer)
(with-current-buffer buffer
(save-excursion
(goto-line 1)
(setq dir-path (get-current-line))
;; If buffer empty, then user has cancelled or the open failed.
;; If only one line in buffer, then only one file selected, so use it.
(when (> (buffer-size) 0)
(if (= 1 (setq lines-in-page (count-lines 1 (buffer-size))))
(if (fboundp 'w32-browser)
(w32-browser dir-path)
(if other-win
(find-file-other-window dir-path)
(find-file dir-path)))
(while (> lines-in-page 1)
(decf lines-in-page)
(forward-line)
(setq file-fqn (concat dir-path "/" (get-current-line)))
(save-excursion
(if (fboundp 'w32-browser)
(w32-browser file-fqn)
(if other-win
(find-file-other-window file-fqn)
(find-file-noselect file-fqn)))))))))) ; no display
(kill-buffer buffer)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 23 Oct 2021 20:54:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 23 Oct 2021 at 16:45, Stefan Kangas <stefan <at> marxist.se> wrote:
>
> What I want is more or less the exact behavior of xdg-open, but I want
> to be able to check the actual command (e.g. "evince", not just
> "xdg-open") before pressing RET.
>
I don't understand why this is useful. If you want a particular command for
every file of a type, configure it; if you want a particular command this
time, specify it.
I also want to be able to override xdg-open with customizations inside
> Emacs.
>
This just adds complexity to the system.
Please bare with me as I'm trying to understand.
>
"bear" ;)
Is your preference still to just run "xdg-open", as you explained in
> your original bug report?
Yes.
Do you agree that if we could get my idea to work, you could have your
> cake and eat it too?
No, because I was hoping we could make the cake smaller.
IOW, do you disagree with the approach because you
> think it is infeasible to make it work well, or because you don't think
> that the feature sounds useful? Or do you merely disagree with using
> mailcap to implement it?
>
I agree with Eli that mailcap is not a good match; also it's widely
considered deprecated (for example, GNOME's mechanism doesn't use it), so
its configuration is likely to be out of date.
Mostly, I am afraid that a suggestion which satisfies everyone in terms of
functionality will simply pile on more features to Emacs, in an area which
is already too complicated. I don't see why launching external applications
can't be left to the operating environment, as all environments now have
mature systems for doing this. If someone such as you wants more complex
functionality, that can be served by a third-party package; it doesn't need
to be built in to Emacs.
--
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 24 Oct 2021 05:11:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 18132 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> Reuben Thomas <rrt <at> sc3d.org> writes:
>
>> xdg-open uses the underlying desktop system's MIME infrastructure. For a
>> GNU system, that would most typically be GNOME, and its "gio open" (or on
>> older systems, gvfs-open) command.
>
> I don't see that shooting away blindly to xdg-open is satisfactory; the
> user should be able to a) know which command is being run before running
> it and b) modify it on the fly. Maybe I want to open PDF:s first with
> one and then another PDF reader to see if it looks the same, just as I
> would be able to from a graphical file manager.
>
> Thus, the most important question to my mind is "how can we get the
> default command for a file in the best way".
Helm is using an alist to store (command . extension), if no command is
found, it uses mailcap to find a default unless the user specify a new
association interactively (prefix arg), user can add arguments to the
command if needed, before or after the filename(s) arguments.
In addition, on GNU/Linux it is possible to detach the process from
Emacs.
See helm-external.el, I am working on it currently.
--
Thierry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 24 Oct 2021 06:03:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Reuben Thomas <rrt <at> sc3d.org>
> Date: Sat, 23 Oct 2021 21:53:17 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 18132 <at> debbugs.gnu.org
>
> I also want to be able to override xdg-open with customizations inside
> Emacs.
>
> This just adds complexity to the system.
Yes, but the added complexity should be small, and I think we cannot
do without that: tools like xdg-open will never be able to satisfy all
the needs of Emacs users, because Emacs is not just a file manager
capable of starting applications.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 24 Oct 2021 07:58:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> I also want to be able to override xdg-open with customizations inside
>> Emacs.
>>
>> This just adds complexity to the system.
>
> Yes, but the added complexity should be small, and I think we cannot
> do without that: tools like xdg-open will never be able to satisfy all
> the needs of Emacs users, because Emacs is not just a file manager
> capable of starting applications.
To add minimal complexity we could use as an example
the recent design of context-menu-functions that is a hook.
Then we could create a new customizable hook that can contain
a list of functions that return the command candidates depending
on the argument with file names.
Then its possible options for such hook could include:
- xdg-open-function
- mailcap-function that adds mailcap candidates
- dired-x-guess that adds existing dired-guess-shell-alist-default
- Windows-specific candidates from w32-shell-execute
- etc.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 24 Oct 2021 16:36:02 GMT)
Full text and
rfc822 format available.
Message #95 received at submit <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> linkov.net> writes:
>> Such a command emulates what double clicking on an icon does
>> which most of the time is what a user wants (because it's
>> configured it do what their most common app need is).
>
> Such a command is long overdue. I used the following command
> for a long time, and forgot it's not in dired-x. I don't suggest
> to use this implementation, but something like this.
FWIW, my version is quite different:
#+begin_src emacs-lisp
;;; open a file as if double clicking on its icon
(declare-function w32-shell-execute "w32fns.c")
(defun hrm-open-file (file)
"Open FILE as the system would."
(interactive "fFile: ")
(cond ((memq system-type '(darwin))
(call-process-shell-command (concat "open " (shell-quote-argument file))))
((memq system-type '(windows-nt))
(w32-shell-execute "open" (convert-standard-filename file)))
((memq system-type '(gnu/linux))
(call-process-shell-command (concat "xdg-open " (shell-quote-argument file))))
(t
(error "Open not supported on this system"))))
(defun dired-do-open (&optional arg)
"Open the marked (or next ARG) files as the system would."
(interactive "P")
(mapc #'hrm-open-file (dired-get-marked-files nil arg)))
#+end_src
--
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 24 Oct 2021 19:18:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> FWIW, my version is quite different:
>
> (cond ((memq system-type '(darwin))
> (call-process-shell-command (concat "open " (shell-quote-argument file))))
> ((memq system-type '(windows-nt))
> (w32-shell-execute "open" (convert-standard-filename file)))
> ((memq system-type '(gnu/linux))
> (call-process-shell-command (concat "xdg-open " (shell-quote-argument file))))
Indeed, these are good system-dependent default values for the new
hook-like user option.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Thu, 23 Nov 2023 18:05:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> To add minimal complexity we could use as an example
> the recent design of context-menu-functions that is a hook.
>
> Then we could create a new customizable hook that can contain
> a list of functions that return the command candidates depending
> on the argument with file names.
>
> Then its possible options for such hook could include:
>
> - xdg-open-function
> - mailcap-function that adds mailcap candidates
> - dired-x-guess that adds existing dired-guess-shell-alist-default
> - Windows-specific candidates from w32-shell-execute
> - etc.
Here is the implementation:
[shell-command-guess.patch (text/x-diff, inline)]
diff --git a/lisp/simple.el b/lisp/simple.el
index 2e2d73e9bf4..25e0c1cca7f 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -4273,8 +4273,63 @@ shell-command-default-error-buffer
is run interactively. A value of nil means that output to stderr and
stdout will be intermixed in the output stream.")
+(defcustom shell-command-guess-functions
+ '(shell-command-guess-mailcap
+ shell-command-guess-xdg
+ shell-command-guess-dired)
+ "List of functions that guess shell commands for files.
+Each function receives a list of commands and a list of file names
+and should return the same list of commands with changes
+such as added new commands."
+ :type '(repeat
+ (choice (function-item shell-command-guess-dired)
+ (function-item shell-command-guess-xdg)
+ (function-item shell-command-guess-mailcap)
+ (function :tag "Custom function")))
+ :version "30.1")
+
+(defun shell-command-guess (files)
+ "Return a list of shell commands, appropriate for FILES."
+ (let ((commands nil))
+ (run-hook-wrapped 'shell-command-guess-functions
+ (lambda (fun)
+ (setq commands (funcall fun commands files))
+ nil))
+ commands))
+
(declare-function mailcap-file-default-commands "mailcap" (files))
+
+(defun shell-command-guess-mailcap (commands files)
+ (require 'mailcap)
+ (append (mailcap-file-default-commands files) commands))
+
(declare-function dired-get-filename "dired" (&optional localp no-error-if-not-filep))
+(declare-function dired-guess-default "dired-aux" (files))
+
+(defun shell-command-guess-dired (commands files)
+ (require 'dired-aux)
+ (append (ensure-list (dired-guess-default files)) commands))
+
+(declare-function xdg-mime-apps "xdg" (mime))
+(declare-function xdg-desktop-read-file "xdg" (filename &optional group))
+
+(defun shell-command-guess-xdg (commands files)
+ (require 'xdg)
+ (let* ((xdg-mime (when (executable-find "xdg-mime")
+ (string-trim-right
+ (shell-command-to-string
+ (concat "xdg-mime query filetype " (car files))))))
+ (xdg-mime-apps (unless (string-empty-p xdg-mime)
+ (xdg-mime-apps xdg-mime)))
+ (xdg-commands
+ (mapcar (lambda (desktop)
+ (setq desktop (xdg-desktop-read-file desktop))
+ (propertize
+ (replace-regexp-in-string
+ " .*" "" (gethash "Exec" desktop))
+ 'name (gethash "Name" desktop)))
+ xdg-mime-apps)))
+ (append xdg-commands commands)))
(defun minibuffer-default-add-shell-commands ()
"Return a list of all commands associated with the current file.
@@ -4284,8 +4339,7 @@ minibuffer-default-add-shell-commands
(let* ((filename (if (listp minibuffer-default)
(car minibuffer-default)
minibuffer-default))
- (commands (and filename (require 'mailcap nil t)
- (mailcap-file-default-commands (list filename)))))
+ (commands (and filename (shell-command-guess (list filename)))))
(setq commands (mapcar (lambda (command)
(concat command " " filename))
commands))
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 02194e6ff45..ba6685af7f3 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -763,22 +763,6 @@ dired-trample-file-versions
;;; Shell commands
-(declare-function mailcap-file-default-commands "mailcap" (files))
-
-(defvar dired-aux-files)
-
-(defun dired-minibuffer-default-add-shell-commands ()
- "Return a list of all commands associated with current Dired files.
-This function is used to add all related commands retrieved by `mailcap'
-to the end of the list of defaults just after the default value."
- (interactive)
- (let ((commands (and (boundp 'dired-aux-files)
- (require 'mailcap nil t)
- (mailcap-file-default-commands dired-aux-files))))
- (if (listp minibuffer-default)
- (append minibuffer-default commands)
- (cons minibuffer-default commands))))
-
;; This is an extra function so that you can redefine it, e.g., to use gmhist.
(defun dired-read-shell-command (prompt arg files)
"Read a Dired shell command.
@@ -789,14 +773,9 @@ dired-read-shell-command
Use `dired-guess-shell-command' to offer a smarter default choice
of shell command."
- (minibuffer-with-setup-hook
- (lambda ()
- (setq-local dired-aux-files files)
- (setq-local minibuffer-default-add-function
- #'dired-minibuffer-default-add-shell-commands))
- (setq prompt (format prompt (dired-mark-prompt arg files)))
- (dired-mark-pop-up nil 'shell files
- 'dired-guess-shell-command prompt files)))
+ (setq prompt (format prompt (dired-mark-prompt arg files)))
+ (dired-mark-pop-up nil 'shell files
+ 'dired-guess-shell-command prompt files))
;;;###autoload
(defcustom dired-confirm-shell-command t
@@ -1316,7 +1295,7 @@ dired-guess-default
;;;###autoload
(defun dired-guess-shell-command (prompt files)
"Ask user with PROMPT for a shell command, guessing a default from FILES."
- (let ((default (dired-guess-default files))
+ (let ((default (shell-command-guess files))
default-list val)
(if (null default)
;; Nothing to guess
@@ -3856,9 +3835,6 @@ dired-vc-deduce-fileset
(setq model (vc-checkout-model backend only-files-list))))
(list backend files only-files-list state model)))
-(define-obsolete-function-alias 'minibuffer-default-add-dired-shell-commands
- #'dired-minibuffer-default-add-shell-commands "29.1")
-
(provide 'dired-aux)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Thu, 23 Nov 2023 19:41:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 23 Nov 2023 19:49:44 +0200
>
> > Then its possible options for such hook could include:
> >
> > - xdg-open-function
> > - mailcap-function that adds mailcap candidates
> > - dired-x-guess that adds existing dired-guess-shell-alist-default
> > - Windows-specific candidates from w32-shell-execute
> > - etc.
>
> Here is the implementation:
Thanks, but please don't put this stuff in simple.el. There's no
reason to have this preloaded in Emacs. And let's try to implement
this in a way that won't load mailcap, xdg, dired, and dired-aux
whenever shell-command is invoked.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Fri, 24 Nov 2023 08:23:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> > Then its possible options for such hook could include:
>> >
>> > - xdg-open-function
>> > - mailcap-function that adds mailcap candidates
>> > - dired-x-guess that adds existing dired-guess-shell-alist-default
>> > - Windows-specific candidates from w32-shell-execute
>> > - etc.
>>
>> Here is the implementation:
>
> Thanks, but please don't put this stuff in simple.el. There's no
> reason to have this preloaded in Emacs.
I can't find other place to put these 50 lines. I added to simple.el
near read-shell-command because it's used by read-shell-command.
If you want this could be moved to dired-aux.el and placed
near dired-guess-shell-command. But would it be quite inappropriate
since shell-command-guess is a more general feature?
> And let's try to implement this in a way that won't load mailcap, xdg,
> dired, and dired-aux whenever shell-command is invoked.
It already doesn't load mailcap, xdg, dired, and dired-aux
when shell-command is invoked. It loads these files only
when the user needs to use them and types 'M-n' twice in the
minibuffer of read-shell-command ('M-!' and 'M-&').
Also shell-command-guess is used by dired-read-shell-command
('!' and '&' on a file in dired).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Fri, 24 Nov 2023 14:26:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 18132 <at> debbugs.gnu.org
> Date: Fri, 24 Nov 2023 09:51:54 +0200
>
> >> > Then its possible options for such hook could include:
> >> >
> >> > - xdg-open-function
> >> > - mailcap-function that adds mailcap candidates
> >> > - dired-x-guess that adds existing dired-guess-shell-alist-default
> >> > - Windows-specific candidates from w32-shell-execute
> >> > - etc.
> >>
> >> Here is the implementation:
> >
> > Thanks, but please don't put this stuff in simple.el. There's no
> > reason to have this preloaded in Emacs.
>
> I can't find other place to put these 50 lines. I added to simple.el
> near read-shell-command because it's used by read-shell-command.
IMO, read-shell-command should not by default call these helpers.
If we cannot find a suitable non-preloaded file to put this stuff (is
subr-x.el okay, for example?), it's okay to start a new file.
> > And let's try to implement this in a way that won't load mailcap, xdg,
> > dired, and dired-aux whenever shell-command is invoked.
>
> It already doesn't load mailcap, xdg, dired, and dired-aux
> when shell-command is invoked. It loads these files only
> when the user needs to use them and types 'M-n' twice in the
> minibuffer of read-shell-command ('M-!' and 'M-&').
That's immaterial: M-n is an integral part of shell-command (of any
command, really), and thus should not cause such massive loading of
helper stuff, not by default anyway. Why do we think we can
second-guess what user wants from shell-command guessing? why do we
think the user will want XDG in this picture? or mailcap? These are
explicit user preferences, and we should leave it to the users to
express their preferences.
> Also shell-command-guess is used by dired-read-shell-command
> ('!' and '&' on a file in dired).
Likewise here: users should by default be able to invoke these Dired
commands without automatically loading those helpers, which come with
quite tangible ballast. For Dired, this is perhaps less important,
since Dired itself is an optional package, but still: I think it's
wrong to do this by default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 25 Nov 2023 18:22:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> >> > Then its possible options for such hook could include:
>> >> >
>> >> > - xdg-open-function
>> >> > - mailcap-function that adds mailcap candidates
>> >> > - dired-x-guess that adds existing dired-guess-shell-alist-default
>> >> > - Windows-specific candidates from w32-shell-execute
>> >> > - etc.
>> >>
>> >> Here is the implementation:
>> >
>> > Thanks, but please don't put this stuff in simple.el. There's no
>> > reason to have this preloaded in Emacs.
>>
>> I can't find other place to put these 50 lines. I added to simple.el
>> near read-shell-command because it's used by read-shell-command.
>
> IMO, read-shell-command should not by default call these helpers.
It doesn't call them by default.
> If we cannot find a suitable non-preloaded file to put this stuff (is
> subr-x.el okay, for example?), it's okay to start a new file.
Ok, then let's add this to dired-aux.el since it's used in dired.
>> Also shell-command-guess is used by dired-read-shell-command
>> ('!' and '&' on a file in dired).
>
> Likewise here: users should by default be able to invoke these Dired
> commands without automatically loading those helpers, which come with
> quite tangible ballast. For Dired, this is perhaps less important,
> since Dired itself is an optional package, but still: I think it's
> wrong to do this by default.
Ok, I removed mailcap and xdg from defaults:
[shell-command-guess.patch (text/x-diff, inline)]
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 02194e6ff45..0c01b24c2db 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -763,22 +763,6 @@ dired-trample-file-versions
;;; Shell commands
-(declare-function mailcap-file-default-commands "mailcap" (files))
-
-(defvar dired-aux-files)
-
-(defun dired-minibuffer-default-add-shell-commands ()
- "Return a list of all commands associated with current Dired files.
-This function is used to add all related commands retrieved by `mailcap'
-to the end of the list of defaults just after the default value."
- (interactive)
- (let ((commands (and (boundp 'dired-aux-files)
- (require 'mailcap nil t)
- (mailcap-file-default-commands dired-aux-files))))
- (if (listp minibuffer-default)
- (append minibuffer-default commands)
- (cons minibuffer-default commands))))
-
;; This is an extra function so that you can redefine it, e.g., to use gmhist.
(defun dired-read-shell-command (prompt arg files)
"Read a Dired shell command.
@@ -789,14 +773,9 @@ dired-read-shell-command
Use `dired-guess-shell-command' to offer a smarter default choice
of shell command."
- (minibuffer-with-setup-hook
- (lambda ()
- (setq-local dired-aux-files files)
- (setq-local minibuffer-default-add-function
- #'dired-minibuffer-default-add-shell-commands))
- (setq prompt (format prompt (dired-mark-prompt arg files)))
- (dired-mark-pop-up nil 'shell files
- 'dired-guess-shell-command prompt files)))
+ (setq prompt (format prompt (dired-mark-prompt arg files)))
+ (dired-mark-pop-up nil 'shell files
+ 'dired-guess-shell-command prompt files))
;;;###autoload
(defcustom dired-confirm-shell-command t
@@ -1316,7 +1295,7 @@ dired-guess-default
;;;###autoload
(defun dired-guess-shell-command (prompt files)
"Ask user with PROMPT for a shell command, guessing a default from FILES."
- (let ((default (dired-guess-default files))
+ (let ((default (shell-command-guess files))
default-list val)
(if (null default)
;; Nothing to guess
@@ -1340,6 +1319,64 @@ dired-guess-shell-command
;; If we got a return, then return default.
(if (equal val "") default val))))
+(defcustom shell-command-guess-functions
+ '(shell-command-guess-dired)
+ "List of functions that guess shell commands for files.
+Each function receives a list of commands and a list of file names
+and should return the same list of commands with changes
+such as added new commands."
+ :type '(repeat
+ (choice (function-item shell-command-guess-dired)
+ (function-item shell-command-guess-xdg)
+ (function-item shell-command-guess-mailcap)
+ (function :tag "Custom function")))
+ :group 'dired
+ :version "30.1")
+
+;;;###autoload
+(defun shell-command-guess (files)
+ "Return a list of shell commands, appropriate for FILES."
+ (let ((commands nil))
+ (run-hook-wrapped 'shell-command-guess-functions
+ (lambda (fun)
+ (setq commands (funcall fun commands files))
+ nil))
+ commands))
+
+(declare-function mailcap-file-default-commands "mailcap" (files))
+
+(defun shell-command-guess-mailcap (commands files)
+ (require 'mailcap)
+ (append (mailcap-file-default-commands files) commands))
+
+(declare-function dired-get-filename "dired" (&optional localp no-error-if-not-filep))
+(declare-function dired-guess-default "dired-aux" (files))
+
+(defun shell-command-guess-dired (commands files)
+ (require 'dired-aux)
+ (append (ensure-list (dired-guess-default files)) commands))
+
+(declare-function xdg-mime-apps "xdg" (mime))
+(declare-function xdg-desktop-read-file "xdg" (filename &optional group))
+
+(defun shell-command-guess-xdg (commands files)
+ (require 'xdg)
+ (let* ((xdg-mime (when (executable-find "xdg-mime")
+ (string-trim-right
+ (shell-command-to-string
+ (concat "xdg-mime query filetype " (car files))))))
+ (xdg-mime-apps (unless (string-empty-p xdg-mime)
+ (xdg-mime-apps xdg-mime)))
+ (xdg-commands
+ (mapcar (lambda (desktop)
+ (setq desktop (xdg-desktop-read-file desktop))
+ (propertize
+ (replace-regexp-in-string
+ " .*" "" (gethash "Exec" desktop))
+ 'name (gethash "Name" desktop)))
+ xdg-mime-apps)))
+ (append xdg-commands commands)))
+
;;; Commands that delete or redisplay part of the dired buffer
@@ -3856,9 +3893,6 @@ dired-vc-deduce-fileset
(setq model (vc-checkout-model backend only-files-list))))
(list backend files only-files-list state model)))
-(define-obsolete-function-alias 'minibuffer-default-add-dired-shell-commands
- #'dired-minibuffer-default-add-shell-commands "29.1")
-
(provide 'dired-aux)
diff --git a/lisp/simple.el b/lisp/simple.el
index 02c68912dba..f27c3042d9a 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -4273,7 +4273,6 @@ shell-command-default-error-buffer
is run interactively. A value of nil means that output to stderr and
stdout will be intermixed in the output stream.")
-(declare-function mailcap-file-default-commands "mailcap" (files))
(declare-function dired-get-filename "dired" (&optional localp no-error-if-not-filep))
(defun minibuffer-default-add-shell-commands ()
@@ -4284,8 +4283,7 @@ minibuffer-default-add-shell-commands
(let* ((filename (if (listp minibuffer-default)
(car minibuffer-default)
minibuffer-default))
- (commands (and filename (require 'mailcap nil t)
- (mailcap-file-default-commands (list filename)))))
+ (commands (and filename (shell-command-guess (list filename)))))
(setq commands (mapcar (lambda (command)
(concat command " " filename))
commands))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 26 Nov 2023 10:38:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 18132 <at> debbugs.gnu.org
> Date: Sat, 25 Nov 2023 20:10:40 +0200
>
> Ok, I removed mailcap and xdg from defaults:
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Mon, 27 Nov 2023 17:38:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> Ok, I removed mailcap and xdg from defaults:
>
> Thanks.
So now pushed to master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Tue, 28 Nov 2023 17:28:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> So now pushed to master.
Here is a patch that adds an option to use a system-dependent command
to open a file:
[shell-command-guess-open.patch (text/x-diff, inline)]
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 47e97c96ce1..e945052b571 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1329,6 +1329,7 @@ shell-command-guess-functions
(choice (function-item shell-command-guess-dired)
(function-item shell-command-guess-mailcap)
(function-item shell-command-guess-xdg)
+ (function-item shell-command-guess-open)
(function :tag "Custom function")))
:group 'dired
:version "30.1")
@@ -1380,6 +1381,29 @@ shell-command-guess-xdg
xdg-mime-apps)))
(append xdg-commands commands)))
+(defcustom shell-command-guess-open
+ (cond
+ ((executable-find "xdg-open")
+ "xdg-open")
+ ((executable-find "run-mailcap")
+ "run-mailcap")
+ ((eq system-type 'ms-dos)
+ "start")
+ ((eq system-type 'cygwin)
+ "cygstart")
+ ((eq system-type 'windows-nt)
+ "open")
+ ((eq system-type 'darwin)
+ "open"))
+ "A shell command to open a file externally."
+ :type 'string
+ :group 'dired
+ :version "30.1")
+
+(defun shell-command-guess-open (commands _files)
+ "Populate COMMANDS by the `open' command."
+ (append (ensure-list shell-command-guess-open) commands))
+
;;; Commands that delete or redisplay part of the dired buffer
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Tue, 28 Nov 2023 17:37:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 18132 <at> debbugs.gnu.org
> Date: Tue, 28 Nov 2023 19:05:46 +0200
>
> + ((eq system-type 'windows-nt)
> + "open")
If this is supposed to be a shell command that can be invoked via the
likes of call-process and start-process, then this should be "start",
not "open" (the latter doesn't exist as an executable command on
Windows).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 29 Nov 2023 07:22:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> + ((eq system-type 'windows-nt)
>> + "open")
>
> If this is supposed to be a shell command that can be invoked via the
> likes of call-process and start-process, then this should be "start",
> not "open" (the latter doesn't exist as an executable command on
> Windows).
Ok, will replace with "start", since only strings are used for commands.
Usually context menus on file managers include two items:
"Open" that opens immediately
"Open With" with a list of commands
So "start" will be used for "Open With" if someone prefers this.
Then a new command 'dired-do-open' bound to the "Open" menu item
will hard-code 'w32-shell-execute' call with the "open" command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 29 Nov 2023 13:08:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: 18132 <at> debbugs.gnu.org
> Date: Wed, 29 Nov 2023 09:09:07 +0200
>
> >> + ((eq system-type 'windows-nt)
> >> + "open")
> >
> > If this is supposed to be a shell command that can be invoked via the
> > likes of call-process and start-process, then this should be "start",
> > not "open" (the latter doesn't exist as an executable command on
> > Windows).
>
> Ok, will replace with "start", since only strings are used for commands.
>
> Usually context menus on file managers include two items:
>
> "Open" that opens immediately
> "Open With" with a list of commands
>
> So "start" will be used for "Open With" if someone prefers this.
> Then a new command 'dired-do-open' bound to the "Open" menu item
> will hard-code 'w32-shell-execute' call with the "open" command.
SGTM, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 02 Dec 2023 17:50:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Usually context menus on file managers include two items:
>>
>> "Open" that opens immediately
>> "Open With" with a list of commands
>>
>> So "start" will be used for "Open With" if someone prefers this.
>> Then a new command 'dired-do-open' bound to the "Open" menu item
>> will hard-code 'w32-shell-execute' call with the "open" command.
>
> SGTM, thanks.
Here is this new command 'dired-do-open':
[dired-do-open.patch (text/x-diff, inline)]
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 1a17ed749e8..7887cc358aa 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1401,6 +1401,32 @@ shell-command-guess-open
"Populate COMMANDS by the `open' command."
(append (ensure-list shell-command-guess-open) commands))
+(declare-function w32-shell-execute "w32fns.c")
+
+(defun dired-do-open (&optional arg)
+ "Open the marked files or at click/point externally."
+ (interactive "P" dired-mode)
+ (let ((files (if arg
+ (dired-get-marked-files nil arg)
+ (save-excursion
+ (mouse-set-point last-nonmenu-event)
+ (list (dired-get-filename nil t)))))
+ (command shell-command-guess-open))
+ (when command
+ (cond
+ ((memq system-type '(gnu/linux))
+ (apply #'call-process command nil 0 nil files))
+ ((memq system-type '(ms-dos))
+ (shell-command (concat command " " (mapconcat #'shell-quote-argument files " "))))
+ ((memq system-type '(windows-nt))
+ (w32-shell-execute (or (and (eq command "start") "open") command) (mapconcat #'convert-standard-filename files " ")))
+ ((memq system-type '(cygwin))
+ (apply #'call-process command nil nil nil files))
+ ((memq system-type '(darwin))
+ (apply #'start-process (concat command " " files) nil command files))
+ (t
+ (error "Open not supported on this system"))))))
+
;;; Commands that delete or redisplay part of the dired buffer
diff --git a/lisp/dired.el b/lisp/dired.el
index 97645c731c8..7f4b96353ee 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2591,6 +2591,9 @@ dired-mode-operate-menu
["Delete Image Tag..." image-dired-delete-tag
:help "Delete image tag from current or marked files"]))
+(declare-function shell-command-guess "dired-aux" (files))
+(defvar shell-command-guess-open)
+
(defun dired-context-menu (menu click)
"Populate MENU with Dired mode commands at CLICK."
(when (mouse-posn-property (event-start click) 'dired-filename)
@@ -2606,6 +2609,9 @@ dired-context-menu
:help "Edit file at mouse click"]
["Find in Other Window" dired-mouse-find-file-other-window
:help "Edit file at mouse click in other window"]
+ ,@(when shell-command-guess-open
+ '(["Open" dired-do-open
+ :help "Open externally"]))
,@(when commands
(list (cons "Open With"
(append
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 02 Dec 2023 18:38:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> Here is this new command 'dired-do-open':
Apologies for taking only a cursory look.
1. It doesn't use the marked files, contrary to the doc.
2. On MS Windows, at least, it doesn't work for files
with embedded space chars.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 03 Dec 2023 17:07:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Here is this new command 'dired-do-open':
>
> Apologies for taking only a cursory look.
>
> 1. It doesn't use the marked files, contrary to the doc.
> 2. On MS Windows, at least, it doesn't work for files
> with embedded space chars.
You are absolutely right. The previous version used wrong assumptions.
Please try a better one:
[dired-do-open-2.patch (text/x-diff, inline)]
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 1a17ed749e8..23c7a9e0027 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1401,6 +1401,36 @@ shell-command-guess-open
"Populate COMMANDS by the `open' command."
(append (ensure-list shell-command-guess-open) commands))
+(declare-function w32-shell-execute "w32fns.c")
+
+(defun dired-do-open (&optional arg)
+ "Open the marked files or a file at click/point externally."
+ (interactive "P" dired-mode)
+ (let ((files (if (mouse-event-p last-nonmenu-event)
+ (save-excursion
+ (mouse-set-point last-nonmenu-event)
+ (dired-get-marked-files nil arg))
+ (dired-get-marked-files nil arg)))
+ (command shell-command-guess-open))
+ (when (and (memq system-type '(windows-nt))
+ (equal command "start"))
+ (setq command "open"))
+ (when command
+ (dolist (file files)
+ (cond
+ ((memq system-type '(gnu/linux))
+ (call-process command nil 0 nil file))
+ ((memq system-type '(ms-dos))
+ (shell-command (concat command " " (shell-quote-argument file))))
+ ((memq system-type '(windows-nt))
+ (w32-shell-execute command (convert-standard-filename file)))
+ ((memq system-type '(cygwin))
+ (call-process command nil nil nil file))
+ ((memq system-type '(darwin))
+ (start-process (concat command " " file) nil command file))
+ (t
+ (error "Open not supported on this system")))))))
+
;;; Commands that delete or redisplay part of the dired buffer
diff --git a/lisp/dired.el b/lisp/dired.el
index 97645c731c8..7f4b96353ee 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -2591,6 +2591,9 @@ dired-mode-operate-menu
["Delete Image Tag..." image-dired-delete-tag
:help "Delete image tag from current or marked files"]))
+(declare-function shell-command-guess "dired-aux" (files))
+(defvar shell-command-guess-open)
+
(defun dired-context-menu (menu click)
"Populate MENU with Dired mode commands at CLICK."
(when (mouse-posn-property (event-start click) 'dired-filename)
@@ -2606,6 +2609,9 @@ dired-context-menu
:help "Edit file at mouse click"]
["Find in Other Window" dired-mouse-find-file-other-window
:help "Edit file at mouse click in other window"]
+ ,@(when shell-command-guess-open
+ '(["Open" dired-do-open
+ :help "Open externally"]))
,@(when commands
(list (cons "Open With"
(append
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sun, 03 Dec 2023 21:17:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> > 1. It doesn't use the marked files, contrary to the doc.
> > 2. On MS Windows, at least, it doesn't work for files
> > with embedded space chars.
>
> You are absolutely right. The previous version used wrong assumptions. Please try a better one:
OK. But why evaluate `system-type' over and
over and over... Just evaluate it once.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Wed, 06 Dec 2023 17:31:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> OK. But why evaluate `system-type' over and
> over and over... Just evaluate it once.
`system-type' is a variable, so it's not evaluated.
OK, now pushed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Thu, 07 Dec 2023 17:35:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 18132 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> OK, now pushed.
More problems: XDG has much better support for media files
than dired-guess-shell-alist-default that contains many
old obsolete and random commands for media files.
OTOH, dired-guess-shell-alist-default has much better support
for non-media files than XDG and mailcap.
So currently there is no way to configure
shell-command-guess-functions to use only best commands.
When shell-command-guess-functions is configured to
'(shell-command-guess-xdg shell-command-guess-dired)
then images are opened with "xloadimage" that doesn't exist.
But when shell-command-guess-functions is configured to
'(shell-command-guess-dired shell-command-guess-xdg)
then images are opened with the existing program like "display",
but then patches can't be applied, because XDG provides
for patch files such useless commands as "more" and "less".
All this can be fixed by this patch that removes old
media commands from 'dired-guess-shell-alist-default'.
Then removed commands will not override media commands
from shell-command-guess-xdg.
[dired-guess-shell-alist-default.patch (text/x-diff, inline)]
diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
index 0998e76c410..de54968bdbe 100644
--- a/lisp/dired-aux.el
+++ b/lisp/dired-aux.el
@@ -1216,28 +1216,28 @@ dired-guess-shell-alist-default
" " dired-guess-shell-znew-switches))
'("\\.pod\\'" "perldoc" "pod2man * | nroff -man")
- '("\\.dvi\\'" "xdvi" "dvips") ; preview and printing
- '("\\.au\\'" "play") ; play Sun audiofiles
- '("\\.mpe?g\\'\\|\\.avi\\'" "xine -p")
- '("\\.ogg\\'" "ogg123")
- '("\\.mp3\\'" "mpg123")
- '("\\.wav\\'" "play")
+ ;; '("\\.dvi\\'" "xdvi" "dvips") ; preview and printing
+ ;; '("\\.au\\'" "play") ; play Sun audiofiles
+ ;; '("\\.mpe?g\\'\\|\\.avi\\'" "xine -p")
+ ;; '("\\.ogg\\'" "ogg123")
+ ;; '("\\.mp3\\'" "mpg123")
+ ;; '("\\.wav\\'" "play")
'("\\.uu\\'" "uudecode") ; for uudecoded files
'("\\.hqx\\'" "mcvert")
'("\\.sh\\'" "sh") ; execute shell scripts
- '("\\.xbm\\'" "bitmap") ; view X11 bitmaps
+ ;; '("\\.xbm\\'" "bitmap") ; view X11 bitmaps
'("\\.gp\\'" "gnuplot")
- '("\\.p[bgpn]m\\'" "xloadimage")
- '("\\.gif\\'" "xloadimage") ; view gif pictures
- '("\\.tif\\'" "xloadimage")
- '("\\.png\\'" "display") ; xloadimage 4.1 doesn't grok PNG
- '("\\.jpe?g\\'" "xloadimage")
+ ;; '("\\.p[bgpn]m\\'" "xloadimage")
+ ;; '("\\.gif\\'" "xloadimage") ; view gif pictures
+ ;; '("\\.tif\\'" "xloadimage")
+ ;; '("\\.png\\'" "display") ; xloadimage 4.1 doesn't grok PNG
+ ;; '("\\.jpe?g\\'" "xloadimage")
'("\\.fig\\'" "xfig") ; edit fig pictures
'("\\.out\\'" "xgraph") ; for plotting purposes.
'("\\.tex\\'" "latex" "tex")
'("\\.texi\\(nfo\\)?\\'" "makeinfo" "texi2dvi")
- '("\\.pdf\\'" "xpdf")
- '("\\.doc\\'" "antiword" "strings")
+ ;; '("\\.pdf\\'" "xpdf")
+ ;; '("\\.doc\\'" "antiword" "strings")
'("\\.rpm\\'" "rpm -qilp" "rpm -ivh")
'("\\.dia\\'" "dia")
'("\\.mgp\\'" "mgp")
@@ -1320,7 +1320,9 @@ dired-guess-shell-command
(if (equal val "") default val))))
(defcustom shell-command-guess-functions
- '(shell-command-guess-dired)
+ '(shell-command-guess-mailcap
+ shell-command-guess-xdg
+ shell-command-guess-dired)
"List of functions that guess shell commands for files.
Each function receives a list of commands and a list of file names
and should return the same list of commands with changes
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Thu, 07 Dec 2023 17:50:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, "18132 <at> debbugs.gnu.org"
> <18132 <at> debbugs.gnu.org>
> Date: Thu, 07 Dec 2023 19:33:53 +0200
>
> More problems: XDG has much better support for media files
> than dired-guess-shell-alist-default that contains many
> old obsolete and random commands for media files.
> OTOH, dired-guess-shell-alist-default has much better support
> for non-media files than XDG and mailcap.
>
> So currently there is no way to configure
> shell-command-guess-functions to use only best commands.
>
> When shell-command-guess-functions is configured to
> '(shell-command-guess-xdg shell-command-guess-dired)
> then images are opened with "xloadimage" that doesn't exist.
>
> But when shell-command-guess-functions is configured to
> '(shell-command-guess-dired shell-command-guess-xdg)
> then images are opened with the existing program like "display",
> but then patches can't be applied, because XDG provides
> for patch files such useless commands as "more" and "less".
>
> All this can be fixed by this patch that removes old
> media commands from 'dired-guess-shell-alist-default'.
> Then removed commands will not override media commands
> from shell-command-guess-xdg.
>
>
> diff --git a/lisp/dired-aux.el b/lisp/dired-aux.el
> index 0998e76c410..de54968bdbe 100644
> --- a/lisp/dired-aux.el
> +++ b/lisp/dired-aux.el
> @@ -1216,28 +1216,28 @@ dired-guess-shell-alist-default
> " " dired-guess-shell-znew-switches))
> '("\\.pod\\'" "perldoc" "pod2man * | nroff -man")
>
> - '("\\.dvi\\'" "xdvi" "dvips") ; preview and printing
> - '("\\.au\\'" "play") ; play Sun audiofiles
> - '("\\.mpe?g\\'\\|\\.avi\\'" "xine -p")
> - '("\\.ogg\\'" "ogg123")
> - '("\\.mp3\\'" "mpg123")
> - '("\\.wav\\'" "play")
> + ;; '("\\.dvi\\'" "xdvi" "dvips") ; preview and printing
> + ;; '("\\.au\\'" "play") ; play Sun audiofiles
> + ;; '("\\.mpe?g\\'\\|\\.avi\\'" "xine -p")
> + ;; '("\\.ogg\\'" "ogg123")
> + ;; '("\\.mp3\\'" "mpg123")
> + ;; '("\\.wav\\'" "play")
> '("\\.uu\\'" "uudecode") ; for uudecoded files
> '("\\.hqx\\'" "mcvert")
> '("\\.sh\\'" "sh") ; execute shell scripts
> - '("\\.xbm\\'" "bitmap") ; view X11 bitmaps
> + ;; '("\\.xbm\\'" "bitmap") ; view X11 bitmaps
> '("\\.gp\\'" "gnuplot")
> - '("\\.p[bgpn]m\\'" "xloadimage")
> - '("\\.gif\\'" "xloadimage") ; view gif pictures
> - '("\\.tif\\'" "xloadimage")
> - '("\\.png\\'" "display") ; xloadimage 4.1 doesn't grok PNG
> - '("\\.jpe?g\\'" "xloadimage")
> + ;; '("\\.p[bgpn]m\\'" "xloadimage")
> + ;; '("\\.gif\\'" "xloadimage") ; view gif pictures
> + ;; '("\\.tif\\'" "xloadimage")
> + ;; '("\\.png\\'" "display") ; xloadimage 4.1 doesn't grok PNG
> + ;; '("\\.jpe?g\\'" "xloadimage")
> '("\\.fig\\'" "xfig") ; edit fig pictures
> '("\\.out\\'" "xgraph") ; for plotting purposes.
> '("\\.tex\\'" "latex" "tex")
> '("\\.texi\\(nfo\\)?\\'" "makeinfo" "texi2dvi")
> - '("\\.pdf\\'" "xpdf")
> - '("\\.doc\\'" "antiword" "strings")
> + ;; '("\\.pdf\\'" "xpdf")
> + ;; '("\\.doc\\'" "antiword" "strings")
> '("\\.rpm\\'" "rpm -qilp" "rpm -ivh")
> '("\\.dia\\'" "dia")
> '("\\.mgp\\'" "mgp")
Thanks. However, to justify such significant changes in this
database, we need much more details: we need to know, for each guess
you want to disable or delete, when and on what platform(s) is or was
it true, when and why and on what platform(s) it stopped being true,
and what replacement(s) are available on modern platforms for those
commands that are no longer useful guesses.
And if the guesses you are removing are supposed to be guessed better
by XDG, then we should do that in a way that still supports systems
without XDG.
We cannot make such changes based only on your personal experience on
the system which you use, because we don't want to break other users'
setups. So we must have these details to make this kind of decisions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Fri, 08 Dec 2023 07:49:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> - '("\\.dvi\\'" "xdvi" "dvips") ; preview and printing
>> - '("\\.au\\'" "play") ; play Sun audiofiles
>> - '("\\.mpe?g\\'\\|\\.avi\\'" "xine -p")
>> - '("\\.ogg\\'" "ogg123")
>> - '("\\.mp3\\'" "mpg123")
>> - '("\\.wav\\'" "play")
>> - '("\\.xbm\\'" "bitmap") ; view X11 bitmaps
>> - '("\\.p[bgpn]m\\'" "xloadimage")
>> - '("\\.gif\\'" "xloadimage") ; view gif pictures
>> - '("\\.tif\\'" "xloadimage")
>> - '("\\.png\\'" "display") ; xloadimage 4.1 doesn't grok PNG
>> - '("\\.jpe?g\\'" "xloadimage")
>> - '("\\.pdf\\'" "xpdf")
>
> Thanks. However, to justify such significant changes in this
> database, we need much more details: we need to know, for each guess
> you want to disable or delete, when and on what platform(s) is or was
> it true, when and why and on what platform(s) it stopped being true,
> and what replacement(s) are available on modern platforms for those
> commands that are no longer useful guesses.
Do you really think it's possible to get a list of all popular commands
available on all platforms?
> And if the guesses you are removing are supposed to be guessed better
> by XDG, then we should do that in a way that still supports systems
> without XDG.
This is just a random list of arbitrary commands.
And the problem is that dired doesn't check with 'executable-find'
if any of them is really installed.
But OK, if you want 100% backward-compatibility,
I will refactor out this list of obsolete commands
into a separate variable used by default.
Then a new value of existing option will allow omitting it.
> We cannot make such changes based only on your personal experience on
> the system which you use, because we don't want to break other users'
> setups. So we must have these details to make this kind of decisions.
I don't know where you get such an idea that it's based
on my personal experience. For my use I customized
dired-guess-shell-alist-user long ago.
Instead of this I'm addressing multiple complains.
Here is just a few after a very quick search,
I remember there were much more:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2008-06/msg00202.html
https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg01952.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Fri, 08 Dec 2023 08:09:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 18132 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: drew.adams <at> oracle.com, 18132 <at> debbugs.gnu.org
> Date: Fri, 08 Dec 2023 09:37:20 +0200
>
> > Thanks. However, to justify such significant changes in this
> > database, we need much more details: we need to know, for each guess
> > you want to disable or delete, when and on what platform(s) is or was
> > it true, when and why and on what platform(s) it stopped being true,
> > and what replacement(s) are available on modern platforms for those
> > commands that are no longer useful guesses.
>
> Do you really think it's possible to get a list of all popular commands
> available on all platforms?
Maybe not all commands on all platforms, but at least we should
investigate those you are suggesting to remove. Here's the list of
them:
dvips
xdvi
play
xine
ogg123
mpg123
bitmap
xloadimage
display
xpdf
antiword
strings
At least some of those I recognize: xdvi and dvips are from TeX Live;
xloadimage is probably from X, antiword is still available (I think),
and strings is part of GNU Binutils, so should be on any system that
can build programs. So I'd like to understand better why we are
removing those.
> > And if the guesses you are removing are supposed to be guessed better
> > by XDG, then we should do that in a way that still supports systems
> > without XDG.
>
> This is just a random list of arbitrary commands.
> And the problem is that dired doesn't check with 'executable-find'
> if any of them is really installed.
Well, then maybe Dired should indeed use executable-find?
Or maybe it's okay not to check, since (AFAIU) these are just
candidates to be suggested to the user?
> But OK, if you want 100% backward-compatibility,
> I will refactor out this list of obsolete commands
> into a separate variable used by default.
> Then a new value of existing option will allow omitting it.
See above: perhaps we should first discuss the principles that guide
you when you decide that some of these commands are "obsolete".
> Instead of this I'm addressing multiple complains.
> Here is just a few after a very quick search,
> I remember there were much more:
>
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2008-06/msg00202.html
This one seems to ask about adding a command not in the list. And it
doesn't complain about xloadimage and display, it says the OP "didn't
like" them.
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg01952.html
This says two things:
. some commands in the list are less capable then others
. XDG can do the job better
To the first point, my response would be: put the better ones first in
the list, but leave the worse ones in the list for those users who
don't have the better alternatives.
To the second point, I repeat what I already wrote in my previous
message: we should also support systems without XDG.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#18132; Package
emacs.
(Sat, 09 Dec 2023 17:24:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 18132 <at> debbugs.gnu.org (full text, mbox):
>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-10/msg01952.html
>
> This says two things:
>
> . some commands in the list are less capable then others
> . XDG can do the job better
>
> To the first point, my response would be: put the better ones first in
> the list, but leave the worse ones in the list for those users who
> don't have the better alternatives.
I completely agree. This is what I tried to do,
but couldn't find a way to refactor this amalgamation
in dired-guess-shell-alist-default. We need to split it
to two parts, so users without XDG will have:
1. better ones from dired-guess-shell-alist-default
2. worse ones from dired-guess-shell-alist-default
And users with XDG should be able to have:
1. better ones from dired-guess-shell-alist-default
2. XDG commands
3. worse ones from dired-guess-shell-alist-default
Probably I'll move the worse ones to a new variable
'dired-guess-shell-alist-default-2'.
This bug report was last modified 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.