[neomutt-devel] To fork or not to fork?

Guyzmo z+mutt+neomutt at m0g.net
Wed Jan 25 21:45:31 CET 2017

This is a very fundamental question of what we all want to make of
Neomutt. Do we want to be just an extended mutt with many patches
applied but following Kevin's work?

Or shall Neomutt be something of its own, and merge in just the
important and relevant patches from mutt, while having significant part
of the project changed, and hopefully modernised?

* Fork
  * more refactoring means more changes - and probably breaking away from mutt.
  * changing to other libraries will change a lot, too.
  * Refactoring
    * [libraries] should more functions be replaced by moving to gnulib or libuv?
    * "libuv" → depends on cmake
  * so.. when to split - and how?
  * change all "mutt" to "neomutt" - in the code, docs, manual etc.
  * "Object Orientedness"..
    dkc:  all mailbox implement the same set of functions, defined in
          struct mx_ops, that way we can have generic code in mx.c that doesn't
          care about underlying implementation, it just calls the open, open_msg,
          close_msg, close callbacks on a mailbox to open a message
          it's mainly for code maintanability, not for speed



More information about the neomutt-devel mailing list