Earl Chase <[email protected]> writes: >> 2. We need a way to allow users to bring their own org-habit parsing >> functions. Maybe a defcustom that is an alist of >> (HABIT_STYLE . parse-func). >> > > This was my eventual goal. But it's too soon to implement this for the > moment. For me, the next steps in this process will be refactoring > org-habit-build-graph and org-habit-insert-consistency-graphs. So, the > habit data structure may still change. The next issue is that I plan > on implementing more than just numeric habits. You'll see that > log-done is actually a "repeater style" habit. Numeric habits will > also be a "repeater style" habit. I am also planning on implementing > "clock style" habits and "table style" habits. Obviously, there is > still a chance that I will end up changing the habit data structure > again in the process of doing that. Once those are implemented and > everything is set in stone, I will definitely open things up so that > users can bring their own parsers. >
Implement a couple internal ones first to figure out a good API to expose to users. This is a very intelligent way to move forward. You've thought this through better then I. >> 3. It would be nice to be able to run multiple habit parsing functions >> on a single headline and combine the results. >> > > What exactly do you mean by combine the results? > So lets say we have a parser for "repeater style" and "clock style". I want to enable both all the time so that I don't have to specify the HABIT_STYLE property. Futhermore, someone should be able to combine "USER-DEFINED style" with another style. This would require some sort of "compose-habit-parser" function that would run each parser and merge the results before generating the graph for an item.
