ghost
commented
13 years ago Confirming it works under Linux. However, there are issues. Not sure on the mechanics, but the current "thread" version with a delay of 0.05 seems to introduce no visible lag in highlighting: I have a 800MHz cpu for my linux machine, and see no lag (linux is believed to be more efficient at making threads); for Windows machine, cpu runs at 2.6Ghz, and I see no lag either. The new "timer" version makes the highlighting lag visible under Linux. Threaded version with 0.15 delay and timer version with 0.05 delay feel equal here. In this state, I would refrain from accepting the pull request, though I may be biased, since I use linux primarily.
titoBouzout
adzenith
Now, this one tries a different approach, using time instead of threading. ( works much better on windows, needs some basic feedback about how it works in different systems )
Previous version, was queuing in a different thread all hits to on_selection_modified.
Timer.cancel was cancelling the last hit and appending a new one. That way we avoided many calls to "highlight word". Implementation required jumps on threads, queue and cancelling a lot of tasks. This added an almost invisible delay on drawing the "highlight".
Now, instead of listening every hit to on_selection_modified, we maintain a timer there, and skip all request with lower time than 0.05 sec ( for example selecting a lot of text ). That way we consume less processor ( by skipping hits without queue and cancelling ), and we also don't need to jump from threads, drawing the highlight at the same time than sublime.
Is very unlikely a user will double click in less than 0.05 sec :P
OK, Regards !