Bug#141183: elm-me+: Please use alternatives for /usr/bin/frm
Jordi Mallach <email@example.com> 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
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
> 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?