Yes. I have no clue, why this is happening, nor what Vim is waiting for. The function called by o/O and hitting <CR> in insert mode is the same. So I don't really believe it's an issue with the function itself.
Ok, the difference I'm seeing in GDB is that when indentexpr=GetClojureIndent(), ex_function() sets the msg_scroll variable to TRUE and the conditional in check_for_delay() triggers a one second sleep.
If indentexpr is unset, then no Vim function is called when o is pressed, the msg_scroll variable stays FALSE and there is no delay.
Here's the relevant part of the edit() function, which calls check_for_delay():
* edit(): Start inserting text.
* "cmdchar" can be:
* 'i' normal insert command
* 'a' normal append command
* 'R' replace command
* 'r' "r<CR>" command: insert one <CR>. Note: count can be > 1, for redo,
* but still only one <CR> is inserted. The <Esc> is not used for redo.
* 'g' "gI" command.
* 'V' "gR" command for Virtual Replace mode.
* 'v' "gr" command for single character Virtual Replace mode.
* This function is not called recursively. For CTRL-O commands, it returns
* and lets the caller handle the Normal-mode command.
* Return TRUE if a CTRL-O command caused the return (insert mode pending).
edit(cmdchar, startln, count)
int startln; /* if set, insert at start of line */
/* sleep before redrawing, needed for "CTRL-O :" that results in an
* error message */
So, it appears that the sleep is there because a Vim function is triggered by o and may produce an error message, so we need to wait for that?
That's pretty much all that I managed to dig up. Perhaps it's time to ask the Vim mailing list.
I went through the indenting code and checked each expression whether it triggers the bug or not. It turned out that there are three places where the bug is triggered:
and two calls to vimclojure#Yank
It seems that there are issues with the poor man's closure approach I used. Eg. vimclojure#Yank yanks text into a register temporarily (I don't know of a function to retrieve the text under the cursor...). The previous register contents are restored afterwards. Similar did MatchPairs for the cursor position. Funnily VimClojureCheckForString does the same without triggering the bug.
Please try the attached patch. It should be functionally the same, while miraculously not triggering the bug...
If there aren't any regression introduced I will commit this as a fix.