None of the hooks actually use this data and as they are called after the replacement has been done, they can query the buffer, should they require information about its content.
The problem with having to pass the data pointer to the hooks is that there could be future situations in where the buffer’s data is not inserted as one contiguous block of memory, for example we could allow constructing a buffer from a storage_t instance.
If we find that the user doesn’t have any BOM versions enabled but do have the non-BOM versions then we update their settings to instead use the BOM versions.
Apart from being simpler to use this wrapper supports adding ‘//BOM’ to the charset name to either consume or produce a byte order marker.
It also converts invalid byte sequences to (ASCII) escape codes, e.g. \x8F.
This was previously placed in the file browser’s action menu and thus probably overlooked by many, even though ⇧⌘A is a very useful key equivalent, since many commands work on the entire project when there is no selection in the file browser.
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.
Unfortunately disabling the “Delete” button is cumbersome because our history is stored with CoreData so knowing the number of items in the history requires a fetch request, which we would not know when to re-run (to update the disabled state when the history is changed).
When the filter string is empty we can use the array controller’s results, but I’m leaving that for the future.
Technically we are unable to delete the pasteboard’s current item so “Clear All” was performing a “Clear All Minus One”. While the new label does not make this clear, it at least does not promise to clear everything.
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 is significantly faster on OS X 10.11.
The API is slightly different so this is probably still faster in macOS 10.12 where there should be less of a performance difference between using Foundation and CoreFoundation.
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 :)
Both of these objects may observe the buffer owned by the document, so we should be sure the observers are gone since closing a document may delete its buffer.
