Logic bug with bit-type auto-tracked habits

[christianboyle]

If you have an auto-tracked habit that is defined as bit-type it will incorrectly toggle the state when multiple events occur in succession that result in an even-numbered state since it's bool and not checking for existing 1 state prior to toggling.

So the result is if I have commit defined as bit-type and make 3 commits it will show as incomplete in the display, but if I make a fourth commit it will be marked complete.

[oppiliappan]

Bit type habits intentionally work like this, a track-up will turn a

• untracked day into a true
• true into a false
• false into a true

a track-down will turn a

• true into a false
• false into an untracked day
• untracked day into an untracked day (no action taken)

I agree that track-up toggling a bit doesn't make much sense, in terms of language, however, it is meant to mimic the function of pressing Enter at the UI.

[christianboyle]

Ah, that makes sense. But it still seems confusing in the case of auto-tracked bit-type habits, because if I make 5 commits it will result in the day being marked false, but if I make 6 then it's true.

Some possible options:

1. Add handling to sum of the numerical value of track-up and track-down calls and if the result is greater than zero it is considered true and takes precedence over the bit-type toggled state.
2. Add a note in the Auto Habits documentation that explains how habits defined as bit-type will result in this type of behavior if you are using it in conjunction with something like Git hooks (and it's probably better to use a numerical goal for Auto Habits).

[skbolton]

I agree with @christianboyle that something needs to change here. I currently don’t use any auto bit habits even though I have some use cases for them. The reason is I have no idea whether my hooks are running for the first time and should track up or if it’s already tracked and should do nothing.

I agree that track-up toggling a bit doesn't make much sense, in terms of language, however, it is meant to mimic the function of pressing Enter at the UI.

This makes sense in the use case of the ui where I can see the affects of pressing enter and realize it didn’t do what I expected to. Hooks into scripts don’t have this luxury.

Ps thanks for this library been using it for weeks now.

[oppiliappan]

The reason is I have no idea whether my hooks are running for the first time and should track up or if it’s already tracked and should do nothing.

I had mentioned this in another thread, but I am thinking of writing some kinda query system, so dijo be fully programmable externally. You can query for the existing value and take actions based on that (roughly).

[skbolton]

That would work