Le dim. 31 mai 2026 à 22:54, Morgan Smith <[email protected]> a écrit : > > 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.
So what I will do once everything is finalized is make individual parser functions public. That will give users the chance to write a function that combines the results of say "org-habit-parse-log-done-todo" and "org-habit-parse-numeric-todo". I would also be open to writing a compose-habit-parser function. But there will be some restrictions. I am planning on creating new properties for "clock style" and "table style" habits since those habit types won't rely on the user having a todo with a timestamp and repeater. However, in the end, those functions will still return a habit data structure with a repeater value, a deadline value and a list of closed dates. So if a user wants to combine a "repeater style" parser and "clock style" parser, the restrictions will be that we will only merge the list of closed dates returned by both functions if both functions return habit data structures with the same repeater value and deadline value. I don't think it makes any sense to combine habits with different repeater values and/or deadline values natively. But again, I will make individual parser functions public so if a user really wants to do that, they can write a function that does that themselves. I would like to make it clear that there will be no distinction between user defined parser functions and the default parser functions. I would also like to make it clear that "repeater style" vs "clock style" or "table style" is just an internal distinction. numeric and log-done habits are "repeater style" habits just because they will share some of the same functions.
