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. :)
On Tue, Jul 12, 2005 at 02:02:42PM -0400, Derek Martin wrote:
> On Tue, Jul 12, 2005 at 10:38:44AM -0700, Brendan Cully wrote:
> > in turn makes me think that general mailbox info should be cached
> > somewhere (to record things like number of messages, number of
> > flagged, number of new, number of unread etc), which leads to bigger
> > architectural changes than I've had time to consider. The IMAP code
> > is crusty enough that this happens to me all the time - little
> > features get put off for until after the bigger rewrite that never
> > happens. I'm not proud of that. Anyway, if mail handling is fixed,
> > your patch probably won't work the same way and becomes a backward
> > compatibility problem.
>
> Yes, yes, yes, yes, yes, yes, yes, and yes. :)
>
> Maybe it's time for Mutt 2.0... ;-)
I would really like to see there be a roadmap. Some people have
argued that it isn't necessary, but I think that's just silliness.
Part of the reason the development process is broken is because there
is no intelligent design process; people simply hack on features that
they want haphazzardly. Admittedly, this hasn't worked SO badly up to
now, but it could be better I think. This is not easily sustainable,
and I think it is also, in large part, what prevents that re-write
you're talking about... 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.
As for what should be a part of the road map, I think the biggest goal
needs to be improving the modularity of the code base. For example:
- wherever code is duplicated, you probably need a macro or a
function
- 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).
- The UI should be completely divorced from the funcntionality.
What I mean is, if someone wanted to, they should be able to
delete the modules pertaining to the UI, and re-write them from
scratch without touching any other code in mutt. It should be
possible to add on an alternative UI, without affecting the
existing one (e.g. to make it easier for a braille user, or a
screen reader, or to add a GUI, etc.), should someone want to do
that. The only code which should be affected is the initial
set-up code to decide which gui is used.
- 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.
- etc...
Obviously these are ideals... It may not always be possible, or rather
it may not always be entirely practical to achieve perfect modularity.
But I think it clearly can be better than it is, and it's definitely
worth attempting. I think improving mutt's modularity will make
extending and maintaining mutt a lot easier in general.
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 ...
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.
I'd also really like to see someone fix the formatting of the code...
I personally hate the GNU coding standards -- I think they're
horrific -- but aside from that whenever I've looked at mutt's code, it
always seems the indentation is inconsistent, sometimes using spaces,
sometimes tabs, etc. One of the (lesser) reasons I hate maintaining
patches is becuase looking at mutt's code gives me a headache. (Ok,
now I'm just grumbling, so I'll shut up...)
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpMfbvREbZD0.pgp
Description: PGP signature