Hi,
since I'm working with larger documents it would be nice if any user event (keyDown, museDown, etc.) could cancel the while/for-loop to find the matching bracket. [maybe in selection.cc - method: find_enclosed_range]
A simple example: - take a file 1.2 MB and 50000 lines [plain text] - select all - press ( to wrap the selection into () - locate caret right of the first ( - move caret to the left - it takes ca. 10 secs before TM accepts the next user event
Kind regards, Hans
PS Sorry for the sent crash report caused by an error which I did while trying something out. Is there a way to avoid sending such reports after compiling TM by myself?
On 29 Mar 2014, at 22:05, Hans-Jörg Bibiko wrote:
since I'm working with larger documents it would be nice if any user event (keyDown, museDown, etc.) could cancel the while/for-loop to find the matching bracket. [maybe in selection.cc - method: find_enclosed_range]
Would probably need some rearchitecturing since adding a “poll” for events in the while loop will likely make it noticable slower, but it does sound like ideal behavior.
That said, the function in question is much slower than it needs to be since it uses regular expressions even when looking for single characters, I choose that because it resulted in simpler code (only one case to handle), but it seems like it should have an alternative (simpler/faster) version for when the “patterns” are just single characters.
PS Sorry for the sent crash report caused by an error which I did while trying something out. Is there a way to avoid sending such reports after compiling TM by myself?
No worries, this is part of the reason why all release builds are odd-numbered. Custom builds should use even numbers (as ./configure sets up the version as “last public release + 1”).
-
Allan Odgaard -
Hans-Jörg Bibiko