Hi Jürgen, I had come up with a solution using self-modifying autocommands:
augroup g1 au! augroup g2 au! augroup end function ShowExtraSpace() au! g1 sy match ExtraSpace / \+\ze\t\|\t\zs \+\|^ \+\|\s\+$/ containedin=ALL endfunction au g1 BufWinEnter,InsertLeave * call ShowExtraSpace() function ShowExtraSpaceInsert() au! g2 sy match ExtraSpace / \+\ze\t\|\t\zs \+\|^ \+\|\s\+\%#\@<!$/ containedin=ALL endfunction au g2 InsertEnter * call ShowExtraSpaceInsert() The "au!" command in each augroup definition is intended to prevent the accumulation of duplicate autocommands whenever _vimrc is sourced. The "au! <group>" command in each function is intended to prevent the accumulation whenever the event associated with that autocommand occurs. This solution works, but your suggestion (after changing "syntax" to "match" in the second autocmd) also works and is simpler. Thank you! It is a mystery to me, though, how this simpler solution avoids the accumulation of autocommands. Maybe an autocommand that uses "syntax match" needs to be kept around on a list, while an autocommand that uses "match" alone doesn't? The "containedin=ALL" may be significant too. Best regards, Dave On Fri, Feb 24, 2023 at 4:13 AM 'Jürgen Krämer' via vim_dev < [email protected]> wrote: > [Quoting re-ordered] > > Hi Dave, > > [email protected] schrieb am 22.02.2023 um 15:47: > > On Tuesday, February 21, 2023 at 5:01:04 AM UTC-5 Dave McCooey wrote: > >> > >> Hello, > >> > >> I recently added the following autocommands to my _vimrc file: > >> > >> :hi ExtraWhiteSpace ctermbg=58 " Orange4 = #5f5f00 > >> autocmd BufWinEnter,InsertLeave * syntax match ExtraWhiteSpace / > \+\ze\t\|\t\zs \+\|^ \+\|\s\+$/ containedin=ALL > >> autocmd InsertEnter * syntax match ExtraWhiteSpace / \+\ze\t\|\t\zs > \+\|^ \+\|\s\+\%#\@<!$/ containedin=ALL > >> > >> With these autocommands in place, I noticed the response time > >> from vim begins to gradually degrade over time: The delay between > >> typing the '.' command and the screen update becomes quite > >> noticeable (longer than 1 second) even if the command being > >> repeated with '.' is simple, like inserting a single space > character. > >> > >> It appears that each switch into and out of insert mode (which is > what > >> happens in a '.' command, and which is what the above autocommands > >> would likely affect) adds a small delay to the next '.' command > that is > >> typed, so that after 30 or so '.' commands, the delay becomes > noticeable. > >> I haven't looked at the source code, but my guess is that each '.' > causes > >> vim to add an element to some list, and this ever-increasing list > needs > >> to be traversed for each subsequent '.' command. > >> > >> I found that switching to a different file and back (":e file" > followed by ":e#") > >> solves the problem by apparently allowing vim to refresh its > internal > >> data structures, but the problem will eventually return as more '.' > >> commands are typed. > >> > >> Without the above buffer-switching remedy, the delay will eventually > >> reach about 2 to 2.5 seconds (on a 3.4 GHz Core i5), at which point, > >> vim will automatically "refresh itself" by disabling all syntax > highlighting, > >> and this removes the delay problem. My guess is that the code has > >> a sort of fail-safe patch that kicks in when a list gets too long. > >> > >> I tested each of the above two autocommands by itself, and each > >> one causes the problem by itself. > >> > >> Best regards, > >> Dave McCooey > >> > > That’s because your autocommand adds a new syntax match every time you > enter insert mode. That probably increases syntax highlighting times and > makes everything else sluggish. Don’t do that for the same reason we use > autogroups. Just add the new match once per buffer (say, autocmd Syntax *). > > or you might want to try if > > :hi ExtraWhiteSpace ctermbg=58 " Orange4 = #5f5f00 > :autocmd BufWinEnter,InsertLeave * match ExtraWhiteSpace / > \+\ze\t\|\t\zs \+\|^ \+\|\s\+$/ > :autocmd InsertEnter * syntax ExtraWhiteSpace / \+\ze\t\|\t\zs \+\|^ > \+\|\s\+\%#\@<!$/ > > works better. > > Regards, > Jürgen > > -- > ~ > ~ > ~ > :wq > > -- > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/vim_dev/843df9ed-cf13-5743-d9c3-0a70783307dd%40googlemail.com > . > -- -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CANGAOmYs3VGMhVJrWjevxg0SLoCzYEZ%3DeVxPOX6FCBGq0gY7gg%40mail.gmail.com.
