Majority of the time in the main thread was spent updating the countOfLeafs property since canReplaceAll and the result text are dependent on this property.
This serves to make the code slightly more abstract and allows the document to optimize the comparison operator, e.g. testing pointer equivalence before involving more complex checks.
We do not display this counter during the search but triggering a KVO notification for each search result has a noticeable overhead and can result in unresponsive UI when the number of results are in the hundreds of thousands.
This relates to documents with many matches on the same (long) line.
Previously we would search for “end of line” per match found, which for a single-line document was effectively quadratic time complexity.
Furthermore we would make a string copy of the entire line for every match. This is now limited to 500 bytes (or longer if the match requires it) with the context before the match being up to 150 bytes (it’s using modulo so adjacent matches should generally show context starting from the same offset).
The test case for the optimization was a 3MB file with only 2 lines and 150,000 matches. After this commit the results are presented in about two seconds (Macbook Pro). Not impressive but much better than before :)
Previously the heuristic used (when files mix LF, CR, and CRLF) for searching files on disk (find in folder) was not identical to the heuristic used when opening files.
This meant that in rare situations a match could be found at what the find in folder determined to be the n’th line, but when opening the file, it was the m’th line (where m != n).
Previously we expected only LF to mark a newline but in theory we can receive CRLF or CR separated text (from files on disk) which would cause incorrect excerpt for matches crossing line boundaries.
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.
The problem with the latter is that a C string is null terminated, but we might have null characters in our string.
Furthermore, the stringWithCxxString: can do a little extra work, like check if the string is NULL_STR or (after next commit) fix redundantly encoded multi-byte sequences.
Effectively we would only test if the prefix of a search result was malformed UTF-8, if the search result itself or the suffix was malformed, no error would be shown.
Since it was one byte it would throw an exception if the last character on the line was a multi-byte sequence (as we’d create an NSString with malformed/truncated UTF-8).
This was previously done because the function wasn’t available until 10.7, but since that is (now) our deployment target, there is no need to wrap the call.
The auto-layout debug mechanisms report that our layout is ambiguous, for example if inserting ‘[self.window visualizeConstraints:_myConstraints]’ at the end of showWindow:.
Closes#1282
Rather than skip the field editor, regardless of which view it belongs to, we check if the first responder is the replace text field’s (current) field editor.
We can get to the next/previous node via the parent pointer, although it has worse time complexity, it’s not something we use in loops, so the extra bookkeeping is not worth it.
When searching for either CR or LF in a CRLF delimited file, we effectively match a partial newline and previously the excerpt’s BOL/EOL positions would not take that into account, so the match wasn’t guaranteed to be a subset of the excerpt.
Ideally the document reader should harmonize newlines so that the searcher only sees LF, though currently that is not the case.
The number appears after command has been held down for 0.2 seconds and is meant as a hint about being able to press ⌘1-n to jump to the n’th file with matches.
