On Friday, July 15 at 09:46 AM, quoth Rocco Rutte:
I think improving mutt's modularity will make extending and maintaining mutt a lot easier in general.Yes, yes, yes. We (the muttng people) share the very same opinion. Also, our standpoint is that this piece of software is a _community_ thing which means that the community has to be involved in developing/designing it (at least by providing feature requests) and not a community thing in the meaning that someone writes code the whole community is free to accept or not. But this requires some discussions about which parts can how be merged into what modules and what are the long term goals to be kept in mind so that they can later be added easily. But as I already wrote in a mail that didn't make it here, I asked for exactly that input on the muttng lists and received this input: 0.
I've made a few suggestions on the bug submission thing. I would guess that your muttng mailing list has very few subscribers (I know I'm not on it). If you're looking for feature ideas without any actual code behind it, well, why didn't you say so! (Are you serious?)
For muttng: ifdef feature_ncurses 'source ~/.mutt-ng/setup-ncurses' ifndef feature_ncurses 'source ~/.mutt-ng/setup-slang' or ifdef feature_slang 'source ~/.mutt-ng/setup-slang' ifndef feature_slang 'source ~/.mutt-ng/setup-ncurses'
A REALLY nice feature would be to be able to do something like: ifdef version_156 'source ~/.mutt_156'It would also be nice if, when backtics (`) evaluate to nothing, mutt(ng) would ignore them. For example, I have this in my config file:
`test -f "$HOME/.muttrc.local" && echo "source $HOME/.muttrc.local" || echo set ascii_chars=no`
I have the "set ascii_chars" thing in there because if I don't, and I don't have a ~/.muttrc.local file, then mutt complains bitterly that I had backticks without anything in them. Or, another example:
`test "$GPG_AGENT_INFO" -a "$GPG_TTY" && echo set pgp_use_gpg_agent=yes || echo set ascii_chars=no`
This is an extension I did to the ifdef patch which adds 'if not defined' and so called "feature tests" to test against a great number of compile-time features (POP, NNTP, IMAP, SASL, even iconv, compressed folder support etc.)
There any way to know what the names of these features are? I don't see them listed anywhere.
And hey, if you're looking for feature suggestions, I've got PLENTY. For example, it'd be nice if color commands could stack. I've got this in my muttrc:
color index cyan default ~U # Unread color index default color8 ~T # Tagged Why should, I have to, then, have a separate rule like this?: color index cyan color8 ~U ~T(This is more important because I have a large list of colors by pattern matching (e.g. all mail from family gets colored green), and I don't want to have to add a separate rule for when each is tagged as well).
Another feature suggestion: make my_hdr able to affect the To: header.Another development suggestion: make mutt's IMAP support not rely on the CHILDREN extension so heavily.
Another development suggestion: put a shorter timeout on IMAP network connections (or make the timeout configurable) so that when I close my laptop and reopen it on another network, I don't have to wait five minutes while mutt realizes the connection to the IMAP server has gone away.
Another feature suggestion: Add a progress-bar of some kind to downloading large messages. To all appearances, mutt freezes when I tell it to view a 3MB mail message over IMAP.
Another feature suggestion: Add a pattern to match messages that are signed with inline pgp rather than pgp-mime.
You want them, I've got plenty of suggestions, and I'm sure plenty of folks who use mutt (or muttng) have them.
~Kyle --The sharpest criticism often goes hand in hand with the deepest idealism and love of country.
-- Robert F. Kennedy
Attachment:
pgp0vwoHQLptx.pgp
Description: PGP signature