Fold more and fold less not working like built-in

[csss1234]

## header
- block
	- note

when carat is on "block" line, (already folded), and i go to menu > fold more, it will collapse the header, because that is "more" folding. but with vim, it requires moving the carat up to the header. it will succesfully fold the "note" into the "block", but pushing it a second time wont then fold the header. any way to get it to function like the built-in "fold more"?

my code

" Toggle current fold
exmap togglefold obcommand editor:toggle-fold
nmap zo :togglefold<CR>

" Unfold all sections
exmap unfoldall obcommand editor:unfold-all
nmap zR :unfoldall<CR>

" Fold less (i.e. unfold one level)
exmap foldreduce obcommand editor:fold-less
nmap zr :foldreduce<CR>

" Fold all sections
exmap foldall obcommand editor:fold-all
nmap zM :foldall<CR>

" Fold more (i.e. collapse one additional header level)
exmap foldmore obcommand editor:fold-more
nmap zm :foldmore<CR>

" Map arrow keys to incremental folding:
" Left arrow: fold more (collapse further)
" Right arrow: fold less (expand one level)
nmap <Left>  :foldmore<CR>
nmap <Right> :foldreduce<CR>

[Threeinone]

:obcommand uses the function executeObsidianCommand which can be found in main.ts:438. The function is pretty simple; it just gets some environment variables, finds the obsidian command by name, and runs the first relevant callback it finds with aforementioned environment variables.

The problem with editor:toggle-fold and editor:fold-more specifically seems to be that their callback functions' behaviour is dependant on if the editor has focus or not. it doesn't whenever you run :obcommand, because the vim command line is active, not the current view.

For instance, the editor:toggle-fold command's callback looks something like this in the app.js:

function(e, t, n) {
    return t.hasFocus() ? !!i() && (e || t.exec("toggleFold"),
    !0) : QI(n) ? (e || n.metadataEditor.toggleCollapse(),
    !0) : void 0
}

So if you have a metadata editor at the top of your note and run :obcommand editor:toggle-fold, it doesn't matter what line your cursor is on--it will actually just toggle the fold on the metadata editor.

[Threeinone]

Determining whether or not the editor has focus is handled by CodeMirror. In this case between the main editor and vim command line, the codemirror-vim extension is what's determining focus. see processEx & showPrompt in the vim.js and openDialog in the cm_adapter.ts.

[Threeinone]

I was looking in the wrong direction in the last two replies.
The issue with editor:fold-more is visible even when you use it from the command palette: The Vim cursor does not update position when folding a heading.

Take the original example md note and place your cursor in the middle of the "block" line, as so.

## header
- blo^ck
	- note

Then activate the editor:fold-more command twice from either the command palette or a hotkey.
what you'll see is that the block cursor is still highlighting the character you had selected in the "block" line, and indeed if you use the keyboard to move the cursor any, the updates to the editor state will unfold the line.

What is causing the undesired behaviour with :obcommand, then, is that the editor state always refreshes when traveling from the command line to the last selected char in the text buffer. In our case, this is always going to be a char from within the active fold, and so it will always unfold the portion the cursor is directly on.

I'm not entirely sure how you would fix this from a plugin scope. The problematic folding behaviour is upstream to Obsidian's implementation of folding (Obsidian creates its own Transaction instance and dispatches it to the Codemirror EditorView, cf. editor foldMore() method at this.app.workspace.activeEditor.editor.foldMore in dev console)
and the automatic state refresh upon executing an Ex command is upstream to Codemirror-vim (this should be where that happens)

The best idea I have is to create a second commands map local to the vimrc-support plugin that shadows over the existing core commands. Any problematic commands like this one can have an entry there, and then executeObsidianCommand() should check the shadow command map first before using normal obsidian commands.