On Sunday, May 5, 2019 at 4:07:29 PM UTC-4, Bram Moolenaar wrote: > > > > After this merge, I experience a noticeable decrease in responsiveness > > > > compared to an earlier version, when a search hits TOP/BOTTOM and > > > > continues on the other end of a large document. > > > > > > > > > > > > That is to be expected. In most files it is OK, but for long files you > > > > > > might want to add the "S" flag to 'shortmess'. That is actually the > > > > > > default, thus you probably set 'shortmess' somewhere. Use this to find > > > > > > out where: > > > > > > :verbose set shortmess? > > > > I can confirm this regression exists even when `&shortmess` contains "S". > > Also, the file I tested with is not in any way a big file (only 8.5kb). > > > > Please revert until this is fixed. > > Try commenting out these lines in search.c: > > if (!shortmess(SHM_SEARCH) > && ((dirc == '/' && LT_POS(pos, curwin->w_cursor)) > || (dirc == '?' && LT_POS(curwin->w_cursor, pos)))) > ui_delay(500L, FALSE); // leave some time for top_bot_msg > > > That is part of the patch that isn't directly related to the "S" flag > and I was wondering if this is good idea. You can also add the "s" flag > to 'shortmess' to see if that makes a difference.
I commented out those lines (while leaving &shm alone), and the behavior seems to have gone back to the way it should be. I hope they will be deleted in the repo. There should be no delay when the search "cycles around". -Manny -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
