Ui

The terminals and the views are implemented in the composite pattern:
terminal.draw will draw the terminal ui by calling the draw function of each view.

The mailbox format is read from the configuration file and with some metaprogramming the correct mailbox type is instantiated and used.  Thus, it should be very easy to add support for another mailbox at present.

I initially wanted to name the Terminal class 'Display', but since termbox has support for capturing key events I think it makes sense to go with this abstraction instead. Even though this leads to the Terminal class having more than one responsibility.  The future will thus bring Terminal.get_key_event, using the tb_poll_event method, which is a blocking call returning an event.  We can then use this event to find out what commands the user issued.

I found a nice dataset, of thousands of emails, used as a training set for machine learning systems tackling automatic spam detection.  The test mail included in the fixture is of somewhat explicit nature, and I expect more to follow :)

If you run this now it will output:

list of maildir folders | the email 
------------------------| itself
list of maildirlabels   | is here

I would like to be, eventually:

folders |        a list of emails in the active folder
--------| ----------------------------------------------------------
labels  |             the currently active email

Right now the size and position of the view is hardcoded in but it needs to be determined dynamically at runtime based on:
-The size of the terminal
-The length of the folder/label names

With tiling window managers being as popular as they are we should recheck the size of the terminal on every draw (termbox has a method for this)