Thoughts on: 1, overly large tabstep; 2, behavior of dragging into insert mode when creating new item

[Ron89]

These are my opinions on vim-orgmode's visual and behavior design.

1. In current version of Org-mode on spacemacs, tabstep appears to be 2, giving a much compact look, comparing to vim-orgmode's default value;
2. Many orgmode functions that generate new items, like creating new checkbox/plainlist with <LocalLeader>cn, when triggered, will drag user into insert mode. I wonder what is behind this behavior design. All functions of orgmode are only accessible on normal mode; navigation in vim is more convenient in normal mode; more importantly, recursive operations would also be more convenient if entering insert mode is cancelled. So I believe the frequent entering of insert mode only hampers workflow.

What do you think?

[jceb]

Thanks for pointing out these issues. Regarding 1, I think the fix should also include the use of formatlistpat. It's not yet set in vim-orgmode but it should make some of the indentation code obsolete as well which relies on 6 space == 1 tab (as far as I remember).

Regarding 2, what's your usecase for adding a new list element without ending up in insert mode?

[Ron89]

1. Yes, current setting for indentation is in org.vim, line 21. I am a bit oblivious on what formatlistpat actually do though, all I know is that it recognizes patterns for headers, which is currently covered in liborgmode/dom_obj.py line 34, as REGEX_CHECKBOX. Do take note that the code for checkboxes might also need changing accordingly if formatlistpat is used instead of simple tab-in. Are you working on this switching?
2. I have been thinking about this for a while.
   • Actually, the original design works well for insert mode adding checkbox/headings. Because in insert mode we deal things sequentially, not breaking back into normal mode does help user focus.
   • But if the user, like when I posted this issue, was editing the file in normal mode, he might tend to structurize thoughts and place-holding hints(like empty checkboxes or empty headings) into various places before going into insert mode and working on details of each again. In this case, the automatic switching into insert mode might break the workflow. So my suggestion would be not changing the mode for user. If user invoke a function from normal mode, stay in it. If he invoke from insert mode, also don't break them out. The latter part is the current behavior design.

[Ron89]

By not entering insert mode after creating new heading, you can also directly demote/promote heading/checkbox/tree, making it more convenient and versatile.

My current arrangement is not breaking out of insert mode if it is currently in when inserting new heading/checkbox. And not forcing users in if those were inserted in normal mode too. Personally I think it is better. I have sent in a pull request. You may checkout and see.

[jceb]

I'm currently not working on any changes for vim-orgmode .. time doesn't permit right now. Regarding demoting/promoting headings and list/check boxes C-d and C-t can be used in insert mode.

Since the change you're suggesting breaks the current behavior, I'd recommend that so more opinions are gathered on how it should work.