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.
We no longer do any reloading of the outline view (on changes) and we have the item store the replacement string when a replacement has been done, so that it will continue to show the actual replacement done (after replacement string is changed).
This only served to disable the Replace All button, we now rely solely on the number of non-excluded and non-ignored results to control the enabled state of the button.
We now bind the enabled state of the “exclude result” checkbox to this property and only set it to YES for files that had replacements done, meaning that the checkboxes are available after replace for files that weren’t involved in the replacement.
When a group node is ignored then it report all its children as excluded regardless of their actual state. It is still possible to query the children for the real state.
