Re: mailcap viewers in dired; gnus-dired.el, mailcap.el

[Juri Linkov <juri@jurta.org>]

> In Emacs 22 (branch), ...
> emacs22 -Q -l mailcap -l gnus-dired -f dired -f turn-on-gnus-dired-mode
> ... loads more than 50 gnusy packages...
>
> ELISP> (length '(gnus-dired gnus-msg gnus-art mm-uu mml2015 pgg
>   pgg-parse pgg-def mm-view gnus-sum nnoo gnus-group gnus-undo nnmail
>   mail-source format-spec gnus-start gnus-spec gnus-int gnus-range
>   gnus-win message rfc822 mml mml-sec mml-smime smime dig mm-decode
>   mm-bodies mm-encode mailabbrev gmm-utils mailheader canlock sha1
>   hex-util gnus nnheader gnus-util netrc mail-utils gnus-ems dired
>   regexp-opt mailcap mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums
>   mm-util mule-util time-date mail-prsvr))
> ==> 56
>
> With these changes, only mailcap and gnus-dired are loaded.

Most of these packages get loaded only for the function `gnus-dired-attach'
in gnus-dired.el which is unrelated to running programs using the mailcap
mechanism.  When I manually eval `gnus-dired-find-file-mailcap' without
loading gnus-dired.el, then the list of loaded packages is much smaller,
maybe only the necessary packages get loaded.

>> Thanks.  Do you see any problems with this?
>
> I did only very limited testing.  I tested that
> `gnus-dired-find-file-mailcap' still works without loading unnecessary
> gnusy packages.  See the preliminary patches (against Gnus trunk)
> below.

I think the goal is not to fix gnus-dired.el to not load unnecessary
packages when only one function is needed from this file, because this
file is already ad-hoc and contains unrelated commands.  I think we should
only look at this file as an example of using the mailcap mechanism and
create a more general commands not in the gnus directory.

> Not a problem, but a TODO: `mailcap-mime-data' should be splitted.
> IMHO, it should be composed of...
>
> (a) entries from a customizable variable
>
> (b) the data from MAILCAPS (`mailcap-parse-mailcaps')
>
> (c) Emacs-wide fallback entries for external viewers (e.g. for
>     Windows), cf. `mailcap-poor-system-types'.
>
> Of course, mailcap.el should prefer (a) over (b), and (b) over (c).

I agree.  This would be a good priority system.

>> gnus-dired.el has a function `gnus-dired-attach' that is Gnus-specific.
>
> I think it could work with any message composition package that
> supports using MML (Emacs MIME).  I don't know if any other exists
> beside (Gnus) Message mode.  But it's MML-specific, yes.

`gnus-dired-attach' already works well for attaching files to the Gnus
messages, so I see no reason to change gnus-dired.el.  What is more useful to
do is to see whether calling mailcap-related functions (not in gnus-dired.el)
will load too many packages.

>> So I think it would be better to leave gnus-dired.el alone, and implement
>> new commands in dired.el or dired-aux.el
>
> I don't use dired often, so I don't have a strong opinion how to
> integrate mailcap functionality there.

`gnus-dired-find-file-mailcap' has a serious deficiency: it always starts
the program that happens to be the first in the list of equal mailcap
alternatives without allowing the user to select the preferable program
and possibly edit its command line.

> I think the other functions `gnus-dired-attach' and `gnus-dired-print'
> could be useful as well (cf. (info "(gnus)Other modes")).  But they
> surely need to be modified for if no other Gnus features should be
> loaded.

`P' (`dired-do-print') could provide a list of available printing commands
from the mailcap file.

>> (and maybe take into account the command guessing behaviour of ! in
>> dired-x.el).
>
> `!' (`dired-do-shell-command') is not exactly what
> `gnus-dired-find-file-mailcap' does.  In mailcap.el you can also
> specify Emacs-internal handling, IIRC.

This is an interesting problem.  It seems that Emacs-internal handling in
mailcap-mime-data mostly duplicates auto-mode-alist, isn't it?

-- 
Juri Linkov
http://www.jurta.org/emacs/