I mentioned a brisk, clean and simple little “stickynote” program for the console the other day, and in the same breath mentioned both hnb and vimwiki. I wanted to add a quick note that I’ve been seeing some strange behavior with vimwiki, on low-end machines.
It seems that the longer, vertically, the page gets, the more lag I encounter when adding or editing material near the end. It’s a little frustrating, but I do notice it at both 550Mhz and at 120Mhz. It only seems to happen when adjusting pages at the bottom, and the page has to be rather long to start with. Shorter pages with a lot of text (perhaps three or four lines wrapped) don’t seem to have the problem, but there’s definitely some sort of processor-based issue at work; the lag is emphasized on the slower machine.
I haven’t seen any bug reports or other complaints elsewhere about the issue, which suggests to me that either everyone else is using vimwiki at a higher clock rate, or making shorter pages. 😉 I do see an occasional note that suggests lag when there are a lot of wiki pages to handle, but that’s not usually the case here. I might have eight pages total, but the lag is really only on the longer, list-like ones.
I’ll poke around a little more and see if I can pin the issue down, and maybe file a bug report. It’s altogether possible that this is something I have done either intentionally or by accident on these customized Crux builds, but it would be nice to at least get some sort of outside verification that I am not imagining things. 😯 😆
Have you tried to turn folding off?
The folding stuff is very slow there especially if folding of list items is switched on.
Check
:h g:vimwiki_folding
:h g:vimwiki_fold_lists