Open RayJameson opened 1 year ago
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.
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
@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
+ -
? :thinking:
@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
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 :slightly_smiling_face: If it's convincing we might merge it into the project. If not, you still get the behavior you want in your personal fork.
@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.
@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?
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