-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Option to set motion timeouts #303
Comments
Can you share the C++ file in question, or at least one having the issue? I agree optimizing find_unmatched using more TS features is needed at this point. Adjusting timeouts is fine but it's better if we can return the result quickly. |
Another thing that we can try is if this suggestion changes the performance: #302 (comment) If so, then it may be isolated to that specific functionality. |
Yeah, I wasn't working with a file this big when I made the feature request, but since I've tested this issue on my desktop instead of my laptop, and to be able to reproduce it I had to create a much larger file |
Interestingly I can't seem to reproduce this. From line 3381 [% goes to line 3147 due to the From line 3382 [% goes to line 3381 again on the Could I be missing anything config-wise? |
Ah sorry, I just can't type, it was 3881 and 3882, I'll update the previous comment just so the reproduction steps should be all there, as for config, I only configured the aforementioned stopline variables, and enabled the treesitter backend. |
Is your feature request related to a problem? Please describe.
I'm working on a large C++ file, with a lot of characters, and after some point, [% and ]% stop working, they always reach the hardcoded timeout of 750ms and give up, MatchupWhereAmI also has similar issues btw (both use the find_unmatched function).
Describe the solution you'd like
It'd be nice to be able to change these hardcoded timeouts through an option, for when you know you're working on large files and don't mind waiting a few seconds for the cursor to move.
Describe alternatives you've considered
I also noticed that, ironically, highlighting the matching bracket was faster than going to it, this seems to be due to it using the treesitter backend, so, idk if it's possible, but maybe it'd help implementing a treesitter based find_unmatched function, which would probably help with the runtime.
Additional context
I tested manually calling the functions with the longer time outs, and they do properly go to the desired bracket, but often take several seconds (which I wouldn't normally mind given how useful they are).
The text was updated successfully, but these errors were encountered: