Jordi Mallach <[EMAIL PROTECTED]> writes: > I've been talking to Jeff about what the priorities should be. Jeff has > pointed out that the mailutils replacements of these tools integrate > well with the rest of the mailutils package: all of these apps use a > variable that makes them look/write mail where you specify in the > variable, including remote imap servers, etc. If installing mailutils > and elm made people use the elm programs by default, it could be very > confusing having all your mail apps but 2 or 3 support this variable.
Hmm, elm-me+ utilities (and mailutils doesn't provide them all) use an elaborate .elmrc, the equivalent variable being `incoming-mailbox', with IMAP and POP support as well. I think it would be even more confusing for elm-me+ users, for the same reason, especially on a multi-user system where they might not even be aware of mailutils getting installed. To use another package as an example: tcsh fixes many csh bugs, has many additional features, and provides a full compatibility mode when invoked as /bin/csh. Nonetheless, the original csh has priority 30, while tcsh has 20. I believe in the principle of least surprise: historically, frm was part of elm, and that's what users have come to expect. > We haven't looked if the three mailutils-based apps support the elm > features. Do you know off-hand? If it's just missing a few, I think the > mailutils upstreams could consider adding them. - elm-me+ frm has `-v' for verbose mode. - elm-me+ frm turns on `-n' when invoked as `nfrm'. Note that GNU Standards deprecate this. - elm-me+ readmsg defaults to the current folder, the current message, and the screen numbering when invoked from within elm (e.g. in an external editor while composing a mail reply). I doubt mailutils will ever implement this. - mailutils readmsg has `-w WEEDLIST' for selecting displayed headers. - elm-me+ messages is a simple shell script and works only with local Unix mailboxes. > Mailutils is under active development right now. elm-me+ isn't unmaintained either. > While we decide what to do, I guess I should add diversions for these > too, and switch to alternatives when we have a consensus. We need an > upload soon as we got a bug filed for a serious bug. I don't think it will take us more than a week to reach a conclusion, so you needn't bother with more diversions (you'll have to remove them later in the preinst). BTW, what serious bug? Thanks, Matej
