Read at most 1 KiB or 50 lines of a file and render the attributed string in a bitmap context.
The theme is set to Mac Classic to ensure a white background for best look when the previews are used as icons in Finder.
The user’s default fixed width font in size 4 is used. With this font size only around 7 lines are shown, so we need to make it smaller, but we probably want to scale down the result to allow fractional line heights.
A lot of code is copy/pasted from the QuickLook preview generator.
This prevents `tableView:objectValueForTableColumn:row:` from throwing an exception (index beyond bounds) when the user deletes the last row while it is being edited.
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.
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.
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.
Fixestextmate/bugs#4
We instantiate the class in the xib file, so the linker does not know that we actually need it.
Currently the filter list framework use MGScopeBar, which is why this issue is not an actual problem (yet).
This was suggested in pull request #1226. Ideally we would make the limit flexible, e.g. see how much we can generate in 1-2 seconds, but that is a non-trivial change, so the fixed limit will do for now, and while truncated data is suboptimal, it’s better than being killed due to QL manager’s timeout.
By using a smaller font size in the bundle table we can show more of the bundle description. Also, it minimizes the amount of resizing of the pane we have to do to see the entire description string for most of the bundles.
When rebuilding textmate from scratch:
git clean -xffd; git reset --hard HEAD; rm -rf ~/build/TextMate/; ./configure; ninja
This error appears:
Frameworks/OakAppKit/src/OakTabBarView.mm:7:9: fatal error: 'OakAppKit/OakFileIconImage.h' file not found
After one issues "ninja" again, textmate continues building fine.
I guess this might be because perhaps OakAppKit's headers are being copied
to the build include directory (~/build/TextMate/include) in parallel when
building OakTabBarView.mm. No matter what actually is the case, this patch
fixes building during clean build.
This new 10.10 API allows one to mark, for some UI element, a set of UI
elements to track selection. VoiceOver (and other accessibility clients)
will then track and announce selection (cursor) changes not only in the
currently focused element, but also for all elements contained in its
"shared focus elements" array. This is a perfect fit for search field
with a table of results. In fact it is used for new 10.10 Spotlight -
its search field's shared focus element is the table containing the results.
As NSAccessibilitySharedFocusElementsAttribute is available only in the 10.10 SDK,
so make a way to use its value with previous SDKs (with which TextMate
is currently compiled).
We also retain the kind-of-hacky solution for pre-10.10 OSes introduced in
and instead use NSAccessibilitySharedFocusElementsAttribute.
This code was tested in all 6 fields of a 3×2 matrix:
* compiled with 10.8, 10.9 and 10.10 SDK
* run on 10.9 and 10.10 (DP2)
For user, this means more standard behavior (says the same "completion selected"
thing as with Spotlight) and a bit more correctness (no extra space
before beginning / after end of search field on braille display).
For developer, this means once we stop supporting 10.9, we will be ready to
drop a lot of code which, while serving us well to make the choosers more
user friendly on pre-10.10, will no longer be needed.
This makes it possible to use ⌘{ and ⌘} to move between the source lists, which is consistent with other windows with multiple sources (like the Preferences and About windows).
Closes#1236.
