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.
