bug#18132: Time for a smarter dired-guess-shell-alist-default? (dired-x.el)

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 22 Oct 2021 22:25:09 -0700
> Cc: 18132@debbugs.gnu.org
> 
> Reuben Thomas <rrt@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.