toggle checkbox -> cycle checkbox? include OrgTSCheckboxHalfChecked

[RayJameson]

Does this feature exist in Emacs orgmode core?

N/A

Orgmode link

No response

Feature value

Would be cool if the checkbox toggle included OrgTSCheckboxHalfChecked, I'm not sure about the value, but I expected it to work like that in the first place.
[ ] -> [-] -> [x]

Additional context

No response

[seflue]

I'm actually not aware, that this behavior exists in Emacs. The half-checked checkboxes are used in hierarchical checkbox trees. If only some of the underlying checkboxes are checked, the parent checkbox get's half-checked automatically.

I'm not sure, what @kristijanhusak would say. My personal oppinion is, that such a feature needs to be optional and could be enabled by a configuration value. For me it would be annoying most of the time, because I just want to toggle my checkboxes fast.

Furthermore I would suggest [ ] -> [X] -> [-] because my expectation would be to have a full-check as default and only occasionally a half-check is needed.

[RayJameson]

I'm not coming from emacs, and not familiar with how it's done there. I just think it's kinda strange to have a keymap that includes 2 out of 3 possible statuses for items.

I agree about [ ] -> [X] -> [-], I can see how some people could even never find out about third status, as they don't use it, so it's not bothering anyone

[jgollenz]

@RayJameson there actually exists something similar in emacs orgmode: https://orgmode.org/manual/Checkboxes.html#index-C_002dc-C_002dc-6

With a double prefix argument, set it to ‘[-]’, which is considered to be an intermediate state.

However, I don't see anything about changing the cycle. I think that is on purpose, referring to the checkbox-state manipulation as a 'toggle' and not a 'cycle', which would infer only two states. I'd say this sounds more like a new keybinding actually. Ctrl + - ? 🤔

[RayJameson]

@jgollenz the idea came not from orgmode, but from me.
I think this would be optimal, however, it could be harder to implement, here is how I imagine it

1st scenario: empty box
[ ] -> [X] -> [-]

2nd scenario: checked box
[X] -> [ ] -> [-]

3rd scenario: half-checked box
[-] -> [X] -> [ ]

Those scenarios would require storing the initial state of the box

If this is too much, a separate keymap for cycling should be fine

[jgollenz]

First of all, nvim-orgmode tries to be a faithful port of orgmode, so replicating the behavior described in the orgmode docs is our immediate goal. The cycling you described, if implemented, would have to live behind a config flag, as @seflue suggested, since it is not part of orgmode.

As for the behavior you described, I'm not convinced that it is easy to grasp. We would need to implement a timer to decide whether we are already coming from one of the scenarios or if we are starting one from the top:

[ ] -> [X] -> user reconsiders and presses Ctrl-Space -> ?

Would you expect [-] here or [ ]? I'd say it depends on how many milliseconds have passed between the two presses of Ctrl-Space. Now we already have two configs: 1. enable checkbox cycle, 2. milliseconds after which we exit a cycle-scenario.

Perhaps this can work, but I'm skeptical. In any case, custom features are not our priority as there are enough actual features of orgmode we are missing. But nonetheless I encourage you to try it out implementing yourself 🙂 If it's convincing we might merge it into the project. If not, you still get the behavior you want in your personal fork.

[seflue]

@jgollenz The simplest version would be just a boolean flag to enable or disable the feature (disabled by default) and when enabled, on toggle the [X] gets replaced by a [-] and that by a [ ]. Adding a timer starts a rabbit hole as you already sketched out. And I agree, it doesn't have priority, but @RayJameson nobody would prevent you from implementing it by yourself and creating a PR.

[seflue]

@RayJameson To give a bit more context how it is handled in Org mode: Emacs has the notion of a prefix argument and a "universial prefix". In Org-mode this prefix is used to manipulate the behavior of org-toggle-checkbox to achieve the intermediate-state (see org manual). I don't know, how we could transfer this into a proper Vim workflow. @jgollenz Any ideas?