[bug-mailutils] Re: [PATCH] Support for mailutils-mh

[Peter S Galbraith]

[Sergey, should address@hidden be included in this discussion?]

Sergey Poznyakoff <address@hidden> wrote:

> Attached is a slightly improved patch.
>  (defun mh-find-progs ()
>    "Find the directories for the installed MH/nmh binaries and config files.
>  Set the `mh-progs' and `mh-lib', and `mh-lib-progs' variables to the
> -directory names and set `mh-nmh-flag' if we detect nmh instead of MH."
> +directory names and set `mh-nmh-flag' if we detect nmh instead of MH,
> +or `mh-mailutils-mh-flag' if we detect Mailutils instead of MH."
> +  (unless (and mh-progs mh-lib mh-lib-progs)
> +    (setq mh-mailutils-mh-flag (load "mailutils-mh" t)))
>    (unless (and mh-progs mh-lib mh-lib-progs)
>      (let ((path (or (mh-path-search exec-path "mhparam")
>                      (mh-path-search '("/usr/local/nmh/bin" ; nmh default

Minor point, but I doubt that we want to cast in stone detection of
`mailutils-mh' by the presence of that elisp file.  Do we?  Wouldn't it
be better it weren't needed?  (It's needed for MH-E V5, but soon only
Emacs20 will still be suing that)

We might want to preferentially install the most feature-rich version by
default (first nmh, then MH, then mailutils-mh; and eventually the order
might have mailutils-mh fisrt) and have a defcustom to pick

 <*> auto-detection
 < > nmh
 < > MH
 < > mailutils-mh

with the unavailable options grayed out (if we can even do that in the
custom interface; I'm not sure).

`mh-version' detects the MH version for various flavours, so I'm sure a
regexp search could tell us which flavour we're using.  Hmmm.  Shouldn't 
`mh-version' and `mh-find-progs' be combined?  We should be setting the
versions and the paths at the same thing, from similar probes.

Okay, I'm thinking out loud.  Comments about it?

Peter