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 *).
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
>
--
--
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/c4d56fbe-83af-421e-b3bf-c9f09d5bf28dn%40googlegroups.com.
