Rather than putting tabs in their own node, leave them in the text nodes and allow core text to handle the size. This fixes the issue with using tabs in right-to-left text.
This was to allow third party indexes but we newer got anywhere with that, so it’s just unnecessary code complexity and the potential for problems if the files on disk are wrong.
I experimented a lot with different combination of attributes, this one works
reasonably well compared to the others (even though it is less feature
complete). I may revisit experimenting with it at some later point.
More specifically item's displayed keyboard shortcut or tab trigger is now
announced by VoiceOver.
Implementation of accessibilityAttributeValue:forParameter: returns nil for
some attributes. This is a hack to avoid doing tedious adjustments of certain
parameterized attributes (like AXStringForRange, AXAttributedStringForRange,
AXBoundsForRange, AXRTFForRange) for string AXValue that is extended (appended)
by extra information at its end in accessibilityAttributeValue:. To get an idea
how tedious this is (even though our case is a bit simpler by not *prepending*
anything before the AXValue, and not being an editable field), look at
OakLinkedSearchFieldCell. This looses the ability for the user to interact with
the text, but considering how seldom this will be used (if at all), for now
this seems acceptable.
This is needed because VoiceOver asks for the *StringForRange attributes and if
implemented, will never query AXValue (which is where our custom behavior is).
In the future when tables will be migrated from cell-based to view-based ones,
the tab trigger or shortcut could be a separate NSView, which would probably
allow for much more elegant solution to this problem.
Previously using ⌘F with a multiline selection would automatically set the “in”
pop-up to “Document”. This is no longer the case, but can be brought back by
running: `defaults write alwaysFindInDocument -bool YES`
This fixes an issue with complex input managers.
Using Chinese pinyin input and entering ‘ci’ followed by ‘1’ to insert first glyph would insert the glyph (‘刺’) and then set the pending marked range (0-2), which would have caret end up in the middle of a multi-byte sequence.
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).
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.
