Introduce TODO class to reduce complexity in plugins and liborgmode

[sotte]

A TODO class (and maybe a 'TODO-workflow' class) would reduce the complexity of some plugins and some classes in liborgmode.

Single responsibility principle ...

[jceb]

Would you give an example for the functionality of that class?

[sotte]

The functionality is pretty limited (but that's rather good). It would only give you the current TODO state and allow to iterate over the next/previous states/sets of states with a nice interface. There shouldn't be a reason to index a list of todos with three indices (like in line 103) just to figure out what TODO is next.

We basically would extract and disassemble the _get_next_state() from the TODO plugin and create a tiny stupid class.

Something like this.

class Todo():
    def next_state(self):
        pass
    def prev_state(self):
        pass
    def is_current_state_done(self):
        pass
    def __str__(self):
        pass

Nowhere else in orgmode we have to find out if a todo is already done or if it needs an action.

What do you think?

[jceb]

Agreed.

[Shurakai]

I just found this issue and I think it's generally a good idea.

However, the "is_current_state_done" method proposed by @sotte assumes too much: There doesn't have to be a DONE state, as they can be named whatever you want. Maybe we should call this a "terminal" state (or is org-mode strict about it? I didn't check).

Furthermore, this class actually needs to know which states are available; should we initialize this class somewhere or should it fetch this information by itself?

This question is quite important as I'd like to implement support for the #+SEQ_TODO attribute. (As described here http://orgmode.org/manual/Per_002dfile-keywords.html#Per_002dfile-keywords )