This is compatible with how TextMate 1.x works. We identify empty lines because we want to ignore them when finding the last line in an indented block, though this commit should not break that, unless the language in question have one of the folding patterns match empty lines and have also enabled indent based foldings.
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.
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
Several crash reports indicate failure to create a CFString (in ct::line_t’s constructor). As we have an explicit UTF-8 check, I am not sure why it would fail, but at least now TextMate should not crash when it happens.
ZWNJ is so common in Persian texts, and its unicode bi-direction class in neutral.
But the representation chunk contains latin characters and are so left-to-right.
So, when ZWNJ is replaced by the representation chunk, rtl texts are rendered incorrectly.
ZWJ and ZWSP are from the same class, but less common at least in Persian texts.
Previously we would fallback on the grammar’s folding patterns unless ‘foldingStartMarker’ was set, which meant setting just the stop marker or indented folding patterns, would be ignored.
The function will unfold anything completely within the range that also touches one of the range’s end points.
This is because the layout will show adjoining folded ranges as a single image, so if the user clicks this, it is unclear which of the ranges to actually unfold (the layout return a range that encompass all the adjoining folds).
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).
This is only relevant for indented soft wrap where e.g. the text following the soft break is underlined: Previously we would then render an underline for the soft break node itself (which normally consists of whitespace).
Based on crash reports this appears to happen for some users, though only reason I can imagine is if the images are not found in the application bundle (which would happen if the application is moved after launch, but that normally cause many things to fail).
