Accessibility visual bounds for a range of a single softline should always
be also visually restricted to the softline. This is in order to be consistent
with implementation in Apple's apps (e.g. TextEdit).
Fixes#1149.
VoiceOver expects AXLineForIndex and AXRangeForLine to be consistent with
the movement by line using arrow up/down. That means it expects "line"
to mean softline.
VoiceOver also distinguishes commands to move by:
* paragraph (hardline): VO-Shift-PgUp/PgDown
* line (softline): VO-up/down
These are available when interacting with the text area (VO-Shift-down).
This commit therefore fixes the AXLineForIndex and AXRangeForLine
to make "line" mean "softline" instead of "hardline" as was the case
until now.
Now links in text (e.g. links to RFCs after installing the Hyperlink Helper bundle)
are announced as such with VoiceOver and it is possible to search for them with
VO-Cmd-L.
TODO:
* launching links with VO-Space is not supported yet, but Enter (Fn-Return)
does the same thing and is even more reliable.
* link URL is not supported, so it is not possible to learn the URL
with VO-Shift-U.
Normally a line matched by both patterns will be decreased by one unit compared to the non-ignored lines immediately above and below. If however the line above was not indented, the line would in theory be decreased to -1 and thus just go back to zero indent for the line following it.
Previously only the text view’s background would affect the window’s opaque property, which made it impossible to have a solid text view background with a transparent gutter.
This would happen if last line was not newline terminated.
The fix does not take into consideration that last line might contain non-ASCII, in which case it should be highlighted.
With responsive scrolling we need to return NO from isOpaque in order to get transparency and we cannot overload the scrollWheel: method (which we use to forward mouse events from the gutter to the text area).
I have also received a few crash reports that might be caused by responsive scrolling and one user has reported “sticky” scroll behavior.
So for now better just disable it, and see if it fixes all these issues.
Fixes#1135
This mode probably did more harm than good — instead we’ll introduce a glob match mode activated by using an asterisk in the filter string, which will then be able to achieve the same.
Previously the character before the potential tab trigger had to be of a different character class. This is now only required when the first character of the tab trigger is a word character.
Initially not-matched characters were made light gray and we also had to explicitly set the color to white when the item was highlighted.
We no longer use color distinction for matched/non-matched characters, and rendering the text as highlighted is handled by the table view (NSCell setup).
This will make it easier to change the logic, since 3 different parts of the file browser depend on it: accepting first responder, selecting items, and single-clicking items.
The output will be inserted corresponding to the subsets selected on each line.
If the output has less lines than the column selection then the additional selected lines are cleared.
If the output has more lines than the column selection then the additional output lines are dropped.
This should be handled better, but previously we would crash due to filling the stack, so better to just immediately abort when we detect the problem, so that we get a better crash report and can see how widespread the issue is.
