RE: relation between `dired-guess-default' and `mailcap-file-default-commands'

[Drew Adams]

> > After filing bug #2028 about `dired-guess-default', I came 
> > across similar uses of `mailcap-file-default-commands'.
> > I'm a bit lost in the code, but it looks like these two
> > functions might be doing double-duty to some extent. IIUC,
> > each returns a list of shell commands that might be
> > appropriate for a given set of target files.
> >
> > The former is used by `dired-guess-shell-command' (hence 
> > indirectly by `dired-read-shell-command' and `dired-man').
> > The latter is used by
> > `minibuffer-default-add-shell-commands' and
> > `minibuffer-default-add-dired-shell-commands'
> > (hence indirectly by `dired-smart-shell-command',
> > which is presumably something similar to functions that
> > employ `dired-guess-shell-command').
> >
> > The means by which `dired-guess-default' and 
> > `mailcap-file-default-commands' produce their lists of
> > shell commands that target files seem to be quite
> > different. Perhaps one of them is superior, or perhaps
> > they should be combined?
> 
> `mailcap-file-default-commands' is superior since it provides real
> commands available on the system.

Granted. But `dired-guess-default' gives the user some control via
`dired-guess-shell-alist-user'. That too is an advantage, unless there is a
similar means for users to add to or prune the candidates found by
`mailcap-file-default-commands'.

> But it's not clear what to do with
> `dired-guess-default': either combine its commands with commands
> from `mailcap-file-default-commands' or remove completely.

Yes, that's the question.

> > It's not clear to me, for instance, why 
> > `dired-read-shell-command' would guess
> > shell commands based on file-type alists and 
> > `read-shell-command' would guess
> > shell commands based on file MIME types.
> 
> Commands from MIME types are based on system information from 
> mailcap files whereas a built-in list in
> dired-guess-shell-alist-default is fixed.

That part is fixed, but the other component, `dired-guess-shell-alist-user', is
not - it is customizable.

And the entire list could of course be made customizable by just moving the
content of `dired-guess-shell-alist-default' to the default value of
`dired-guess-shell-alist-user'. That approach would give the user complete
control, but it wouldn't offer anything in the way of automatic smarts.

> > It also seems a bit odd that simple.el and dired-aux.el 
> > would look to GNUS code for their utility functions. Seems
> > like some code refactoring or cleanup might be in order here.
> 
> Refactoring is already done, so now dependency is minimal.
> Please see http://thread.gmane.org/gmane.emacs.devel/80123/focus=80485

It's already done in the sense of hard code dependencies, perhaps, but it still
doesn't seem quite right (to me) for `mailcap-file-default-commands' to be in a
GNUS file - in a directory that doesn't even use it.

The only code that uses it, in fact, is in files `dired-aux.el' `simple.el', in
the main lisp directory. In particular, that function is not used by anything in
`mailcap.el', where it is defined.

> > If this code organization and seeming duplication or 
> > overlap is intentional, then I would like to understand
> > the rationale (purpose), to better decide which of these
> > functions to use in my own code in different 
> > contexts. The Elisp manual is no help here. If intentional,
> > perhaps the doc strings or commentary could be
> > improved to better explain what each of these is for, that 
> > is, explain their difference in terms of purpose and
> > applicability.

That still sounds like a good idea, to me. Until the functions are merged or one
of them is removed, why not document this? Based on your reply, we should
apparently just tell users to use `mailcap-file-default-commands', not
`dired-guess-default'.

> > Summary: Why are there two, and what is the difference in 
> > terms of intended use? Should they be combined in some way?

Beyond this duplication/overlap, there is also code in
`shell-dynamic-complete-as-command' that comes up with a list of commands. Like
`mailcap-file-default-commands', the list is created dynamically and is based on
the user's actual context (the advantage you spoke of: "real commands available
on the system").

To create this list, yet a third approach is used: examine the user's search
path (`exec-path'). A big difference from the other two methods, however, is
that the candidate commands are not tailored to fit a given list of target
files.

So we seem to have at least three ways of creating a list of shell commands, the
first two of which pick up only real, available commands, and the second two of
which pick up only commands expected to be relevant for a given list of files:

. commands from search path
. file MIME types
. static (user customizable) lists of file types

I still have the question about overlap and possible combination. Should/could
MIME type supplant each of the others? Should some combination be used in all
three contexts?