As the title implies, for me it make sense to let the command determine the default heading level itself when “Toggle Heading” command is triggered. From my point of view.
Currently, after triggering this command, Obsidian will require user to choose the level of heading using a dropdown, which from my point of view doesn’t make much sense since people are using commands to speed up their operation, but the time to move cursor to choose the level is longer than just typing a few “#” symbol in this case.
Possible Solution
For example we could just let the new heading has the same level as the previous heading, like something shown below:
// No previous heading, default level would be H1
# H1
...
// If we use command here, default level will be H1
## H2
...
// If we use command here, default level will be H2
Also, the approach above could also free up the time for user to manually check what’s the right level at current position. Since when executed “Toggle Heading”, he/she knows the new heading must be at the same level as the previous one.
Even if user want to go deeper for one level, he/she just need to add one more # at the beginning.
I don’t like this idea wholly. There is a need for current toggle heading command when you want to change current heading level or remove it. One might also want to insert custom heading level and this request doesn’t describe this case.
Proper implementation would be to offer default choice which can be then changed using ↑/↓ keys.
Thanks for replying and linking the relevant topics.
I think you are right about this, changing the behavior of current “Toggle Heading” may break some other workflows.
However, the issue of needing to manually check the heading level still exists.
All approaches mentioned above still involves the process of manually checking what the current heading level should be (In another word, they are not automatically done). They just use a different way to achieve the action of “check heading level”.
And some of them will also cause a loss of current cursor position. (like by navigate to previous heading using shortcut plugins etc.)
If the current behavior of “Toggle Heading” can’t be changed, then maybe a new command could be added to achieve such functionality.
I agree all of this but is your idea different from the other feature request? They could embed the solution to toggle heading command in the two ways we presented here but this doesn’t add much value so they could just implement such another command to achieve insert same level heading. They already have implemented many special commands like Set as heading 2 so introducing Set as same level heading (or some other cool name) command would be aligned with previous design philosophy.
I also thought about this problem. Unfortunately Code Editor Shortcuts doesn’t offer cursor history navigation and you have to use another plugin like Cursor Position History or Navigate Cursor History. Obviously things start look very ridiculous if you have to use two community plugins to solve this problem.
