Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Fixes and improvements for the Zoom accessibility feature #1242
bol_as_eol was meant for non-empty ranges, but the only place where empty ranges were attempted with bol_as_eol was for Zoom tracking, and it seems like I did not re-test Zoom after making the bol_as_eol commit. Fixes textmate/bugs#4
When setSelectionString is called during editing of text (like inserting or deleting a character), it catches layout in a semi-consistent state where horizontal position of individual characters cannot be determined. Therefore during such events, we cannot pass the correct screen position to the call to UAZoomChangeFocus. So let's do the UAZoomChangeFocus call after this iteration of run loop. This ensures everything in layout that had to update has updated when calling UAZoomChangeFocus, thus enabling us to provide correct horizontal screen position.
This makes Zoom support avoid doing all 2 conversions between UTF-8 to UTF-16, and replaces call to rect_for_range with call to rect_at_index, which is more efficient. Note that this is a typical micro-optimization not resulting from any actual performance measurement, but just from a desire to have a lean code not doing redundant work.
I did not spend much time deciding between the two, I googled a little bit and discovered that
But I am no expert in this topic, so if you feel
I think performSelector:withObject:afterDelay: is the proper idiom for Cocoa code, timer or no timer (my money is on the latter) it has a well-defined behavior of “run this after the current iteration of the event loop”. If you rework the code, can you also ensure only one blank line after the new method introduced?…
On 15 Jul 2014, at 10:47, Boris Dušek wrote: Actually just read the docs and it is not 100% clear whether a timer is used with delay of 0, but says the selector is queued to be executed ASAP, so not sure what to use. --- Reply to this email directly or view it on GitHub: 42906e1#commitcomment-7009411
I will do it this evening, after testing the change I will make a new commit just with the new change (instead of git push --force with the change squashed into this commit, in order not to mess up this conversation history on GitHub issues). I will look out for the new line ;-)
I wouldn’t call this a “micro-optimization”, as O(n) code has been replaced with API that is expected to be O(lg N) or better.
FYI the old code did cause a noticeable slowdown (when zoom was enabled) for large files (multiple hundreds of kilobytes), so this improvement is much appreciated :)