For this change I have made the FFDocumentSearch class inherit from NSDocument. This way, we can register it with the window controller and will get callbacks when the window is about to close, with the option to cancel closing of the window. This approach seems much simpler than the alternative, which would be to introduce our own callback/delegate system for window closing, or have the window controller know about saving files.
We now show “Stopped.” as status text when search is prematurely terminated.
Closing window also cause search to stop.
The stop button has ⌘. as key equivalent (the standard “cancel” key).
Don’t let the stop action go via the search action dispatcher.
If the user does a folder search then ⌘G will step through all the matches, opening documents as required. Previously the user would have to do a new search, using a different search string, to stop ⌘G from moving to a new document. It is now possible to stop the behavior using ⌘F followed by ↩.
This is the action method sent by the Edit → Find → Find All (⌥⌘F) menu item, and is now treated as an alias to the existing findAll: action method (that the Find All button in the find dialog sends).
Untitled documents have no path, so we were creating a dictionary with a nil object. The path isn’t actually used (we go via the identifier) so removing the potential path from the dictionary avoids the problem.
Previously we ignored clicks and only selected matches when the selection was changed. This was done to prevent firing off two “select match” actions. We now ignore the “selection changed” notification if the current event is a mouse-up.
I find myself often closing folder search results and later re-opening (via ⇧⌘F) which would previously have the status string cleared, yet the results still showing.
Status should probably be stored together with the folder search results, so when toggling between document and folder search, the status string would follow as well.
Previously doing a Find All in Document would stay with Find All as the default button, even if closed and re-opened.
We also clear the status text, this isn’t always desirable, but I find it more weird when the dialog shows an outdated status message.
The Find object is assigned to a variable with (guarded) static storage, so the initializer of the Find object will run with a lock on the guarded variable, which turns out to be shared with all other guarded variables.
When setting up the window controller, from the Find object’s initializer, we create a “recent folders” menu which hold icons with SCM badges.
When creating these SCM icons, blocks are scheduled (asynchronously) to “fetch status”. These asynchronous blocks will need to lock the same mutex as we currently have locked (because we haven’t yet left the initializer).
The issue is that we also schedule synchronous blocks on the same queue, and that’s why we get a deadlock, because those can’t run before the asynchronous blocks have finished, yet those are waiting on the global lock that our main thread has currently obtained.
Fixes#874.
Currently this is implemented in OakTextView which means that it doesn’t work for macros. Some refactoring is in order so that the implementation can be shared (lack of sharing has to do with how OakTextView reports status to Find dialog or via tool tips, and macros want none of that).
There is also no check to see if the current state of the editor is the result of a find operation, i.e. you can invoke “replace” regardless of wether or not “find” was the last action.
Finally, doing a multi-file search and using “find next” at the end of one document, which brings you to the first match of next document (part of the results), will not update “captures” from a potential regular expression search, meaning that if you then do “replace”, and your replacement string is a format string that references the match (via $1-n) then it will not be correctly expanded.
Closes#104.
Previously there was a single replace action and the options would indicate if it was a “replace all”, this mimics the “find” (which can be a “find all”) but since single match replacement is somewhat different than a “replace all”, as the former may need to know the captures from a previous find action, it makes sense to factor out these things as different actions.
This is work in progress but I don’t think any functionality is missing compared to previous commit, although some functionality might be less polished, e.g. the action buttons don’t properly enable/disable and the height of the results list gets lost when hiding it.
Some of the stuff that has changed / improved:
* The find/replace text fields adjust their height to encompass the content (closes#94). Presently though the initial height of the ontrols is one line regardless of content (but they should adjust on first edit).
* You can use Save All (⌥⌘S) to save affected files after Replace All (closes#558).
* The key equivalents / actions available in the Find dialog is now easier to find via the action pop-up, which also has enables accessibility.
* Using Next (⌘G) or Previous (⇧⌘G) with search results will move selection up/down.
* Using Find All with ‘in’ set to ‘Selection’ will find and select all matches in the current document, which fixes#425, though it might be more desirable to show the results in the find dialog (like Find All does for a document or folder).
These are expensive to create and it was noticeable when lots of files matched and the menu had to be created (as it would when the user press a potential menu key like ⌘W).
The FFWindowController class is an implementation detail where the Find class is the public class, so depending on the latter should make the code safe against potential rewrites.
My memory is a little vague here, but I believe the point of handling the menu keys was to workaround a bug in NSMenu.
The bug was that NSMenu would look at (the target of) cached menu items, probably for UI validation, so potentially sending methods to unretained objects, which could lead to a crash. Several workarounds were attempted (like clearing the target property after the menu had been displayed) but the only effective one was overloading key handling.
I’m quite sure though that this bug is no longer relevant.
Removed the ability to specify wether documents should open in current window or a new window — all documents opened via this API will go through the same algorithm to find where the documents should end up (more choice is just adding confusion and complexity).
Normally this wouldn’t be noticed, as the second action would do the same as the first (go to the result in the associated project window), but when there was no project window a new window opens (to show the result), and that would be done twice.
This fixes issue #281.
There is still an issue with successive selections for the “no project window” situation, as each time, a new window is opened, rather than reuse the first one that opened.
If user opens the dialog on one space, moves to another space (with a TextMate window) and then re-activate the (already open) dialog, it would previously switch back to the space containing the dialog, whereas with the changed setting, it now moves the dialog to the active space.
This should address issue #599.
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
