sublimehq
typing insinde brackets [] slows to a crawl
Description of the bug
I've confirmed this happens in safe mode so it doesn't seem related to a plugin: With markdown syntax, typing inside brackets [like this] will slow down as the text inside the brackets grows larger. This happens regardless of whether or not a link/url is provided after the bracketed text. As I type something inside the brackets, there is a longer and longer delay between what I'm typing and what is mirrored on the screen. Is there supposed to be a limit in markdown to how long a link can be?
Steps to reproduce
- safe mode 2. select markdown syntax. 3. enter brackets []. 4. type something inside the brackets. as the text grows longer the delay between what you type and what is mirrored on the screen will increase.
Expected behavior
Typing inside brackets shouldn't be any slower than typing outside brackets.
Actual behavior
The more I type inside the brackets, the longer the delay. This happens in markdown, but not in plaintext.
Sublime Text build number
4134 & 4121
Operating system & version
ubuntu 20.04.4
(Linux) Desktop environment and/or window manager
xfce (xubuntu)
Additional information
I got the same behavior in a virtual machine running Windows 10.
OpenGL context information
OpenGL Context Information:
GL API Version: 4.6 (Core Profile) Mesa 21.2.6
GLSL Version: 4.60
Vendor: Intel
Renderer: Mesa Intel(R) UHD Graphics 630 (CFL GT2)
I can reproduce a slowdown for long link descriptions, which becomes noticibla as of about 1000-1500 chars.
Please note, that ST's syntax engine has limitations with regards to performance of long lines in general. The more complex a syntax definition is and the longer a line becomes, performance degrates.
That's not a problem in normal source code, as line lengths are limited to about 100-200 chars.
But in Markdown lines may become very long, especially if a lazy writing style is applied which relies completely on word wrapping.
Link descriptions shouldn't contain too much content in general - not sure what value a whole page of link text has - but as those may not contain line feeds, they probably suffer from long lines most - without a workaround (by changing writing style).
I tried to remove most of the more complex patterns for debugging purposes, but a noticible slow down in writing is not beyound 3000 chars per line.
While the regex causing this could be improved to be faster it actually triggers a bug in our custom regex engine causing exponential behavior. With a fix there's no slowdown even up to the line-limit of syntax parsing.
