These settings are also consulted for “pair movement”, i.e. ⌃↓/⌃↑ and ⇧⌘B, so by using regular expressions we can match begin/end tags and navigate between these.
The algorithm now handle overlapping character ranges like: ‘(f{o)o}’ and unpaired characters surrounded by character pairs.
This is for selecting (⇧⌘B) and moving to the begin or end of the range (⌃↓/⌃↑).
If there is one or more selections:
dyn.selection
If there is a single zero-width selection:
dyn.caret.mixed.columnar
If there are multiple carets and/or selections:
dyn.caret.mixed
When there is only a single caret or a single continuous selection the left scope may contain:
dyn.caret.begin.line
dyn.caret.begin.document
Likewise the right scope may contain:
dyn.caret.end.line
dyn.caret.end.document
The methods going to “begin of indented line” will go to the first non-whitespace character on the line, unless the caret is already there or to the left of this character, in which case it will go to the actual beginning of the line.
The “end of indented line” methods work similarly.
If you want [⇪]⌘⇠/⇢ and ⌘⌫/⌦ to use this behavior, you can add the following to your key bindings file:
"@\UF702" = "moveToBeginningOfIndentedLine:";
"$@\UF702" = "moveToBeginningOfIndentedLineAndModifySelection:";
"@\UF703" = "moveToEndOfIndentedLine:";
"$@\UF703" = "moveToEndOfIndentedLineAndModifySelection:";
"@\U007F" = "deleteToBeginningOfIndentedLine:";
"@\UF728" = "deleteToEndOfIndentedLine:";
This will find (forwards or backwards) but preserve the existing selection.
Presently if the current selection is a zero-width selection (i.e. caret) then we still preserve it. This might not be desired, but one could imagine “extend selection” used with a regular expression which use a look-around assertion (resulting in zero-width matches).
When we need to work on a paragraph (reflow, unwrap, select, etc.) we now extend upward until we see a blank line, and likewise move downward until there is a blank line.
This is related to issue #154.
There is a bunch of functions that deal with the logical column count and these now all count code points with the “east asian width” (unicode) property set as two columns.
This closes issue #206.
