It would be nice to have a test for this.
Or, is it covered by existing tests?

It would be nice to have a test for this.

I cannot add the unit test for it.

Am 2016-09-07 16:00, schrieb Shougo:

It would be nice to have a test for this.

I cannot add the unit test for it.

Since this is done for performance improvement,
can we have some numbers in that case?

E.g. take an example of a file, where completion takes long,
and show how much this improves?

Thanks,

Best,
Christian

E.g. take an example of a file, where completion takes long, and show how much this improves?

I have tested it in 2000 lines Vim script file.

Before: almost 0.1s wait after each input. It is not usable.
After: No wait after each input.

Hi,

2016-9-8(Thu) 0:14:11 UTC+9 Shougo:

E.g. take an example of a file, where completion takes long, and show how much this improves?

I have tested it in 2000 lines Vim script file.

Before: almost 0.1s wait after each input. It is not usable.

After: No wait after each input.

Why you do not disclose the files, settings and operation using the test?

And... I have to say every time, why not a written test?

Best regards,
Hirohito Higashi (a.k.a. h_east)

I agree, a test file together with a recipe on how to hit this issue would be helpful. I tried with a sample 2800 viml file, setup syntax folding (:let g:vimsyn_folding='aflmpPrt' :set fdm=syntax). Unfortunately, for me simple completion using Ctrl-N Ctrl-P is pretty fast.

Then I took my unicode plugin entered letter hit <ctrl-x><ctrl-z> in insert mode with foldmethod=syntax. Did that 3 times with an unpatched and patched vim. Results:

Doesn't look like much difference to me. (Note, first run is always slower, because unicode.vim needs to read in the data from a file).

Second, I am wondering, if the change in fold.c is really needed, it seems, setting the disable_fold_update should be good enough or perhaps add a pum_visible() into that condition.

Oh, sorry. I should upload the test file and test script.

https://gist.github.com/Shougo/5334465

Reproduce ways:

$ vim -u test.vimrc -U NONE -i NONE --noplugin neocomplcache.vim
Press :2922<CR>
Press oneo<C-p><C-n>complcache

You can notice the slowness and the patch fixes it.

Then I took my unicode plugin entered letter hit in insert mode with foldmethod=syntax. Did that 3 times with an unpatched and patched vim. Results:

Unfortunatelly, I cannot reproduce the slowness with your script.

Second, I am wondering, if the change in fold.c is really needed, it seems, setting the disable_fold_update should be good enough or perhaps add a pum_visible() into that condition.

I did, but it cannot fix the problem.
I think the folding update should be ignored in insert mode.

if (State & INSERT && (foldmethodIsExpr(wp) || foldmethodIsSyntax(wp)))
    return;

to

if (State & INSERT)
    return;

It is simpler and disable_fold_update variable is not needed.

What do you think?

I would like to hear more opinions on this. Would it be generally considered useful to disable folding in insert mode? I can imagine how this is getting in the way, but would it be generally considered an improvement? Can we have some more opinions on that?

If we want to change it, that should probably be done after the release of vim 8. So we probably have some time to discuss this.

I cannot see a single case in which I would like to have folds updated while I'm typing. Whatever the fold method.

I'm with @romgrk.

I have an autocmd that disables folds when I enter insert mode automatically. I found it really frustrating when a fold would just update as I type.

Right here.

I have updated the patch.

• Remove disable_fold_update variable
• Ignore folding update in insertmode

I have added compl_busy check.

Sorry, compl_busy is not global variable.
I have removed compl_busy check.

I have fixed the tests failure.

I have fixed the compile error in Tiny.

I have removed the global state and function.

The continual update of syntax folds, especially in TeX files with conceallevel > 0, bogs down Vim in insert mode. Even with an autocmd disabling syntax folding in insert mode, there's a noticeable lag when leaving insert mode.

This is the sole reason for why I made https://github.com/Konfekt/FastFold.
Looking for example at the TeX plug-in vimtex, the documentation at

https://github.com/lervag/vimtex/blob/7e2793d4e3b661a09c091ae30dd6b3162e9febe0/doc/vimtex.txt#L423

shows that this slowness editing TeX files is a recurrent problem.

The continual update of syntax folds, especially in TeX files with conceallevel > 0, bogs down Vim in insert mode. Even with an autocmd disabling syntax folding in insert mode, there's a noticeable lag when leaving insert mode.

Yes. The fix does not fix the insertleave lag.
But it is intended. Because, if the insertleave update is removed, current folding behavior is broken(Current tests are failed).
I think you should set foldmethod=manual if you are really annoyed with the lag.

I can change the fix to ignore the updates if foldmethod is "syntax" or "expr" though.
What do you think?

I can change the fix to ignore the updates if foldmethod is "syntax" or "expr" though.
What do you think?

This would make sense, because then the user can add autocmds to ensure updates at its will. As it stands, the new option does the same as the autocmds en/disabling manual folding on entering/leaving insert mode. Currently, the user still had to set foldmethod=manual to avoid the lag on leaving insert mode.

I have disabled insert leave update if foldmethod is manual, syntax and expr.

I also have an autocommand to dsable the folding in insert mode.

I also have an autocommand to dsable the folding in insert mode.

Please don't comment if you have a similar autocommand. It would more
help to get feedback regarding the actual patch, e.g. does it work as
expected, any issues? Thanks.

Best,

Christian

Alter macht immer weiß, aber nicht immer weise.
-- Sprichwort

I would like to hear more opinions on this. Would it be generally considered useful to disable folding in insert mode? I can imagine how this is getting in the way, but would it be generally considered an improvement? Can we have some more opinions on that?

The idea was that I am also annoyed by the behavior of the folding in insert mode (where it makes no sense) and I would like to see the patch making into VIM.

So, I was just giving my oppinion that such a patch would be necessary. I didn't tested the patch because at the moment I cannot compile vim8 in cygwin, but I will test it as soon as this is doable.

I have improved if checks.

This looks too simplistic. Perhaps folding should be postponed only when editing within one line, but updated when going to a new line? Either when typing Enter or using cursor keys.

This is old and there is too much doubt whether this is an improvement, therefore closing. Feel free to reopen if one can argue why this is really an improvement.

Regarding whether this is an improvement, @chrisbra asked whether

it [would] be generally considered useful to disable folding in insert mode?

and everybody in this thread thought it to be useful.
The discussion whether this is an improvement will likely resemble that whether this is useful.

What was perhaps missing was feedback to @chrisbra 's call for

feedback regarding the actual patch, e.g. does it work as
expected, any issues?