* relation between `dired-guess-default' and `mailcap-file-default-commands'
@ 2009-01-24 23:15 Drew Adams
2009-01-25 1:04 ` Juri Linkov
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2009-01-24 23:15 UTC (permalink / raw)
To: emacs-devel
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?
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.
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.
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.
Summary: Why are there two, and what is the difference in terms of intended use?
Should they be combined in some way?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: relation between `dired-guess-default' and `mailcap-file-default-commands'
2009-01-24 23:15 relation between `dired-guess-default' and `mailcap-file-default-commands' Drew Adams
@ 2009-01-25 1:04 ` Juri Linkov
2009-01-25 3:06 ` Drew Adams
0 siblings, 1 reply; 4+ messages in thread
From: Juri Linkov @ 2009-01-25 1:04 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel
> 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. 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.
> 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.
> 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
> 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.
>
> Summary: Why are there two, and what is the difference in terms of intended use?
> Should they be combined in some way?
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: relation between `dired-guess-default' and `mailcap-file-default-commands'
2009-01-25 1:04 ` Juri Linkov
@ 2009-01-25 3:06 ` Drew Adams
2009-01-25 21:55 ` Juri Linkov
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2009-01-25 3:06 UTC (permalink / raw)
To: 'Juri Linkov'; +Cc: emacs-devel
> > 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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: relation between `dired-guess-default' and `mailcap-file-default-commands'
2009-01-25 3:06 ` Drew Adams
@ 2009-01-25 21:55 ` Juri Linkov
0 siblings, 0 replies; 4+ messages in thread
From: Juri Linkov @ 2009-01-25 21:55 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel
>> `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'.
There is `mailcap-mime-data' but it is not yet defcustom because
it's too big.
>> 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.
I tend to combine them with mailcap commands by putting
dired-guess-shell-alist-user commands to the beginning and
dired-guess-shell-alist-default to the end of mailcap commands.
--
Juri Linkov
http://www.jurta.org/emacs/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-01-25 21:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-24 23:15 relation between `dired-guess-default' and `mailcap-file-default-commands' Drew Adams
2009-01-25 1:04 ` Juri Linkov
2009-01-25 3:06 ` Drew Adams
2009-01-25 21:55 ` Juri Linkov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.