strange bug with `ts$`

[ces42]

Description

I stumbled upon this strange bug. It seems to be very rare so rather low-priority. I can try to look into what's happening once I'm less busy...

Steps to reproduce

1. put this into a tex file

   \[
       \{x \vert \text{$1$ $2$ $3$}\}
       y
   \]
   

2. move the cursor to y and do ts$

Expected behavior

\[ ... \] should turn to \begin{equation} ... \end{equation}

Actual behavior

nothing happens. If the cursor is in the first line of the displaymath everything seems to work fine. If I delete the $3$ things also work fine.

Do you use a latexmkrc file?

no

VimtexInfo

System info:
  OS: Ubuntu 23.10
  Vim version: NVIM v0.11.0-dev-650+ge961627956
  Has clientserver: true
  Servername: /run/user/1000/nvim.370829.0

VimTeX project: tex
  base: tex.tex
  root: /home/ca/build/vimtex/test/perf-syntax
  tex: /home/ca/build/vimtex/test/perf-syntax/tex.tex
  main parser: fallback current file
  document class: 
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
  viewer: General
  qf method: LaTeX logfile

[lervag]

Thanks! That's definitely an edge case! The reason for this is here:

https://github.com/lervag/vimtex/blob/539a203f19531c6b9d2d1b093ee8911fb7050bbc/autoload/vimtex/delim.vim#L440

I.e., I've specified a maximum number of "iterations" in the loop that looks for the correct surrounding delimiters/environment. And at some time, ages ago, I found that this search was slow for math delimiters because there are many of them and the regexes are quite complex. So, I decided to use a very strict and low maximum number here.

It may definitely be possible to relax this. I believe it could be safe and that I may have been a little bit too conservative here. But I don't want to change it much, and if someone complains that VimTeX is suddenly more laggy I would not hesitate to revert such a change. What do you think?

[lervag]

See also #2432; this is where the strict current setting was motivated and added.