Feature Request: more flexibility to define transitions

[hmijail]

Background

Imagine we have a task with a created date, thanks to ToggleList:

- [ ] My task ➕ 2024-01-01

When we use ToggleList again to cycle the task status to "done", the existing date is removed and a new one is added:

- [x] My task  ✅ 2024-04-29

There is no way to define next states like these with a single hotkey:

- [/] My task ➕ 2024-01-01

(note the [/] checkbox)

- [x] My task  ➕ 2024-01-01 ✅ 2024-04-29

Even if we define multiple cycles and hotkeys, for example one to add the creation date ➕ and another to add the finished date ✅, cycling through any of them will remove the corresponding date and re-add today's date (instead of the original one). So going through a cycle causes the existing date to be lost.

Feature Request

It would be great to have a few changes to be able to accomplish these transitions with a single hotkey.

• Allow each state group to be non-cyclical: once the end of the group is reached, that group doesn't evolve further and allows other groups to match. This would allow to have multiple groups assigned to a single hotkey, such that e.g. the creation date group gets stuck when a ➕ is in the line, and then the finished date group can take over to add the ✅.
• Allow greater control over what is matched and what is changed in each transition. Currently, the format {time:: YYYY-MM-DD} is used both for matching (so that YYYY-MM-DD is any date) and for adding today's date in the given format. It would be much more flexible to e.g. use grep patterns with subgroups for replacement, where in the replacement we could also add the {time} variable. For example, to finish a task and add to it a finished date while respecting the existing creation date: match: - [ ] (.* ➕[\d-]) replace: - [x] \1 ✅ {time:: YYYY-MM-DD}

[thingnotok]

Hi @hmijail , thanks for your suggestion. I understand the part about task dates, and actually, you can configure it to cycle through with a single set of shortcut keys like this:

- example task =SG0=> - [ ] example task =SG1=> - [x] example task =SG1=> - [ ] example task

This setup has a limitation in that it cannot revert to the original list, but it should cover most use cases before the next release.

Regarding other parts, could you provide more potential use cases for non-cyclical changes? This would help me figure out which features to develop.

[hmijail]

Your example is helpful, thank you! But it's interesting that I actually tried to change the order of bindings in case it helped to organize the sequence of states, but I couldn't make sense out of it. So maybe some further documentation would help?

As for the non-cyclical changes, it's just one of the ideas I had to control the interaction between groups, to avoid losing information during the transitions. But if the matching is implemented with explicit match and replace fields, then I guess the concept of group is not necessary, so there's no need to deal with their cycles.

Also related: currently I find myself doing this:

1. Type task description
2. Use hotkey until I reach the - [ ] || ➕ date state
3. At this point I want to type the next task, so I would press Enter. But the cursor is now in the middle of the line, so I need to use a hotkey / key combination / mouse to move to the end.
4. Press Enter to go to the new line.
5. Type the next task.

Is there a way to make the cursor jump to the end of the line automatically once a match happens? (please let me know if this should go to a new issue)

[thingnotok]

Yes, the order in which commands are bound can affect which state group is used for lookup first. For groups that bind the same command and share common states, this is an important consideration to keep in mind.

The current design intends for the cursor to remain at the same text position after toggling the state. Based on your usage, the cursor should be at the end of the text before switching states, and it should stay the same after the switch. If this is not happening on your end, it might be a bug. Please send me the text snippet and settings involved in reproducing this issue so I can further investigate.

[hmijail]

State group:

- 
- [ ] 
- [ ] ||  ➕{time:: YYYY-MM-DD}
- [x] || ✅ {time:: YYYY-MM-DD}
{PARAGRAPH}

The hotkey Cmd+Enter is bound to just this group.

Happens with a line containing just "Test", for example.

Obsidian Version 1.5.12 (Installer 1.5.3) ToggleList 1.2.6