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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 23 Oct 2021 01:16:48 -0700
> Cc: rrt@sc3d.org, 18132@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@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.