Re: mutt development and road map
Hi,
* Derek Martin [05-07-14 12:17:27 -0400] wrote:
On Thu, Jul 14, 2005 at 10:45:37AM +0000, Rocco Rutte wrote:
If you still think that there's some good solid code base right now,
just have a look at ci_send_message() in send.c and try describe its
functionality in detail or explain what the exact technical reason is
for having to write the very same code two times for both, the index and
pager, etc.
The problem here is code modularity. IIRC it is a problem mutt
suffers from generally... see below. :)
Not really. In some parts it's totally elegant and should be used as a
good example, like the handling of hundreds of config variables where
you don't need to touch the actual code for changes but just some table
entry. In many other places, tables are used wisely, too. Or the format
strings which are done in a central place, etc.
IMHO the main problem is that the code got extended and will be even
more if one "just" applies all the patches _without_ really merging the
existing with the new funcitonality.
A re-write will require a real development
effort, and neither you nor Thomas (or even both) have the time to do
it alone. You need the help of other coders, and that means having a
real development model, with code design and coordination.
A benefit from the fork of mutt-ng is that some dynamic came into this
but it's still too less. We're thankful for everybody contributing code
and usually, if does the thing, will be accepted within two days if we
have time (take the qdbm support Thomas Glanzmann did for the header
caching which went in within a few days so that qdbm's author noted it
and could even suggest improvements which made it into the code within a
very short time.)
- it should be simple to add support for new mailbox formats... like
adding a driver to an OS kernel. There should be a well-designed
API which higher level code calls to get the I/O it needs from
lower-level mailbox driver code. Adding support for a new
mailbox format should be a simple as adding a single module (plus
the glue code to use it).
See
<http://svn.berlios.de/viewcvs/mutt-ng/trunk/mx.h?rev=289&view=markup>
and, for example, the last two lines of
<http://svn.berlios.de/viewcvs/mutt-ng/trunk/mh.h?rev=289&view=markup>
- for the current UI, configuration should be a little more
consistent (i.e. generic), in cases where it differs based on
compile-time options. That's not clear, so I'll explain... For
example, IIRC the colors you can use in .muttrc change depeding on
whether you compiled with slang or curses. That shouldn't be. If
the colors really can't be matched up, use generic color names.
Mutt could have a help screen to show users what the colors look
like on their terminal.
We received some strange mails where people had some problems because I
heavily did changes on the configuration variables to improve
consistency. For example, there's $mail_check (and a split
$imap_mail_check for muttng) and something called $pop_checkintervall
which is supposed to the very same thing as $mail_check. Yet nobody
can't explain the naming conventions behing it so we renamed many
things. For example, in muttng every variable dealing with IMAP thus is
prefixed with $imap_*, $pop_* for pop etc. These are all very minor but
somewhat important small steps into the right direction. But someone has
to do it.
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.
For cases where it is not possible (or perhaps undesirable) to have
more generic configuration, I'd like to see better conditional parsing
based on compile options, e.g.:
if compiled_with_ncurses
color index ...
else
color index ...
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'
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.)
Ideally the user should be able to write a .muttrc that can be used on
different systems where mutt is compiled with different features, and
still have it behave the same way -- or at least not generate an error
because a specific feature is missing from that version of mutt.
Yes. In muttng you can, of course ;-), do something like this if you
want:
ifndef feature_gpgme 'push q'
to exit if you have some version built without gpgme support. Or you can
only set the $imap_mail_check variable it it's defined:
ifdef imap_mail_check 'set imap_mail_check = 300'
I'd also really like to see someone fix the formatting of the code...
We ran GNU indent over the code and added a script to reformat
everything to common rules.
bye, Rocco
--
:wq!