It is not clear to me whether there was a reason that this code was using the basic_tree_t directly or if it was just written before the indexed_map_t layer was introduced.
The rationale for this is that when empty lines are included it leaves no whitespace between functions.
Example and TextMate 1.x behavior described here: http://pastie.org/private/lgtnlvc8tdvghoppocob5q
Previously when a line was a start or stop marker, and was also matched by `foldingIndentedBlockIgnore` then we would set the line’s indent to INT_MAX to ensure the line would not terminate a foldable indented section, i.e. basically storing the “line should be ignored” in the indent since the line’s type was already set to start or stop marker (rather than “ignored line”).
However, the indent is used to pair start/stop markers, so if only one of a start/stop pair was also matched as an ignored line, they would not be considered a pair because of the different indent levels. The opposite could also be the case, where two lines with different indent were both ignored, and this was seen to share the same indent.
This partially reverts commit 337ac1219d.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
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).
