sluggish cursor when syntax is enabled

[joaocortes]

Hi

I have a document with a lot of equations. In the areas denser in math environments, the cursor becomes very sluggish.

I've followed the advice to disable folding and to set the let g:matchup_matchparen_deferred = 1

When i disable the syntax, the slowdown dissapears.

Is it expected that the syntax alone can be the culprit of the slowdown? If so, is there anything I can do besides disabling the syntax? I anexed

1. a minimal .vimrc file. vimrc_minimal.txt

2. an example of latex code where the problem appears vimtex_slowdown.txt

Thanks

[andymass]

Are you using the plugin match-up or not? It looks like you are not from the minimal vimrc. The option g:matchup_matchparen_deferred will only work if you've installed that plugin. If you still have problems, consider posting an issue to that plugin's tracker. Perhaps the vimtex documentation needs further clarification that match-up is a separate plugin- was this unclear?

Regarding your slowdown issue, vimtex uses syntax to aid its match highlighting, which can be very slow, but match-up uses a different method so syntax on/off should have no effect if you are using match-up.

[joaocortes]

Thanks. Yes, I think some reference to the match-up plugin int the vimtex documentation would be useful: I assumed that g:matchup_matchparen_deferred would only impact vimtex, independently of any other installed plugin. I guess that the option name starting with matchup should have given me an hint, but I am not that used to vim scripting.

I installed match-up, with no apparent efect. Still, disabling syntax solves the problem completely.

I updated the minimal .vimrc example: vimrc_minimal.txt

[andymass]

You also need let g:matchup_override_vimtex=1 in your vimrc.

I am curious though, how did you find out about the option g:matchup_matchparen_deferred besides the section here https://github.com/lervag/vimtex/blob/master/doc/vimtex.txt#L242 which talks about match-up?

[joaocortes]

Its working great. Thanks a lot.

I found it in some closed issue. I can't find wich one exactly. After that, I tried to find more about the option on vimtex.txt , but for some reason searching "match" didn't return anything, so I just follow blindly the suggestion to set g:matchup_matchparen_deferred.

I don't usually update the plugin. I did it now, and after that I could find the section that describes match-up. Maybe the references were updated in the last month or so?

Sorry for the trouble. It must be annoying explaining something that's clearly explained on the references

[joaocortes]

Am I supposed to make the call of closing the issue?

[andymass]

It's no problem at all!

And for closing, maybe we should leave it up to @lervag, because he may consider this an actual issue in vimtex.

The reason matching in vimtex with syntax on is super slow is;

• This function is called many, many, times to determine the "skip" for matchparen. It's unavoidable with searchpairpos() but the problem is vimtex's implementation of the skip function is pretty slow using synstack/synIDattr

https://github.com/lervag/vimtex/blob/b001e771f69888ccb5bfd0f482f0197b669c9718/autoload/vimtex/util.vim#L75

• tex syntax just has a lot of syntax elements, and the syntax functions are slow. I tried using synIDattr(synID(line('.'),col('.'),1),'name') originally and this was too slow for match-up. So, I resorted to strpart(line('.'),0,col('.'))=~?'\\\@<!\%(\\\\\)*%' which isn't perfect but seems to mostly work (I stole this idea from matchit).

[lervag]

First, checking if I understand correctly: This post raises an issue with the feature to highlight matching pairs in vimtex? I've tried to create a minimal working example (see files references in the commit above). When I run nvim -u minivimrc and move around in the buffer, I do see a minor delay when reaching the \begin and \end parts, but nothing major.

I've also tested with matchup, but I see the same delay there. However, it seems that matchup does not correctly disable vimtex's matchparen stuff in this case. Perhaps @andymass can see why that is?

Also, if I understand correctly, @andymass is suggesting that I avoid using the syntax matcher for the skips in searchparpos(). However, I don't see exactly where this is relevant, since there is only one place I use the skip argument:

https://github.com/lervag/vimtex/blob/b001e771f69888ccb5bfd0f482f0197b669c9718/autoload/vimtex/delim.vim#L763

Thus I am probably not quite understanding correctly. My second idea is that perhaps you mean this line, @andymass:

https://github.com/lervag/vimtex/blob/b001e771f69888ccb5bfd0f482f0197b669c9718/autoload/vimtex/matchparen.vim#L48

[lervag]

I'll keep the issue open until I understand whether I should make an action or not. In any case, thanks @joaocortes for reporting and @andymass for contributing so far!

[andymass]

When I run vim -u minivimrc and move around in the buffer, I do see a minor delay when reaching the \begin and \end parts, but nothing major.

I can reproduce this with your MWE (with or without match-up), but I would say it's a "moderate" delay, definitely unacceptable for some users.

However, it seems that matchup does not correctly disable vimtex's matchparen stuff in this case.

I think it's a load-order issue due to silent edit mwe.tex in the minivimrc. This causes vimtex's ftplugin/tex.vim to get sourced before plugin/matchup.vim where I set g:vimtex_matchparen_enabled=0. Ordinarily this probably wouldn't happen, but I added silent! call vimtex#matchparen#disable() to my after/ftplugin/tex_matchup.vim file so order should no longer matter and it seems to work.

However, I don't see exactly where this is relevant, since there is only one place I use the skip argument.

You are absolutely correct, I was mistaken that you were using skip, sorry! Although I had found in_comment() to be slow for my purposes, it is not the cause of this issue.

I think the actual problem is matchadd() in https://github.com/lervag/vimtex/blob/73ca5c326436d7a8e248bf6cb0ee8d89027cf112/autoload/vimtex/matchparen.vim#L61

The problem goes away for me if you replace that with the following:

let w:vimtex_match_id1 = matchaddpos('MatchParen',
        \ [[l:open.lnum, l:open.cnum, strlen(l:open.match)]])
let w:vimtex_match_id2 = matchaddpos('MatchParen',
        \ [[l:close.lnum, l:close.cnum, strlen(l:close.match)]])

You may want to wrap that in a exists('*matchaddpos') since I think that was added sometime in 7.4.

(that all being said I still don't understand why syn off makes any difference with matchadd(..)

[lervag]

I think it's a load-order issue due to silent edit mwe.tex in the minivimrc. This causes vimtex's ftplugin/tex.vim to get sourced before plugin/matchup.vim where I set g:vimtex_matchparen_enabled=0. Ordinarily this probably wouldn't happen, but I added silent! call vimtex#matchparen#disable() to my after/ftplugin/tex_matchup.vim file so order should no longer matter and it seems to work.

Yes, I also expected there might be a load order issue. I think your fix should work well!

... You may want to wrap that in a exists('*matchaddpos') since I think that was added sometime in 7.4.

Thanks, this is a good suggestion! I've added it. I remember that I once used this before, but I guess I removed it when I realized matchaddpos was new. And I was probably not aware of the delay that matchadd gave.

(that all being said I still don't understand why syn off makes any difference with matchadd(..)

Neither do I. This is not, as far as I can understand, a syntax specific issue.