In the Komodo documentation, on the page for “Find & Replace”, in the section titled “Scope”, it mentions the ability to “Search in sub-directories: If selected, makes the search recursive. The search starts in the directory or directories specified above and descends into all sub-directories.” However, I don’t see that option anywhere. Please see the attached screenshot. I’m using version 11.1.1. Perhaps that feature was added later?
It’s a bit unclear, but it’s the arrow after directories. Its a toggle for searching in sub directories
Thank you! Yes, it’s definitely not clear. All this time I’ve been thinking that bent arrow was just an icon added as eye-candy. 
Every once in a while, when I search in subdirectories using Komodo, it seems to miss some of the instances of the search string, but I could never figure out why. Now I see a pattern: It finds the string in files that are located in immediate subdirectories, but not in subdirectories of those subdirectories – in other words, further down in the directory tree. Is there a way to make Komodo search recursively down through all subdirectories regardless of depth? (All along I’ve been assuming that that’s what the subdirectory option was supposed to be doing.)
@mjross, that’s odd. I definitely use that all the time and it works for me. Just double checked with a very contrived test and confirmed that. Here’s some screenshots.
Search settings (right clicked on test-folderserch-komodo in places and clicked “Find…”):
Search Result:
Could you provide similar screenshots and maybe we can figure out what’s up in your case?
@careyh, thank you so much for your reply and your efforts to create a test scenario. I did the same on my end (Win 10 CLI output, simplified):
D:\tmp\test-foldersearch :: dir
2020-11-09 02:37 PM <DIR> .
2020-11-09 02:37 PM <DIR> ..
2020-11-09 02:37 PM <DIR> blah2
2020-11-09 02:37 PM <DIR> blah3
2020-11-09 02:37 PM 7 file1.txt
D:\tmp\test-foldersearch :: type file1.txt
blah1
D:\tmp\test-foldersearch :: type blah2\blah2.txt
blah2
D:\tmp\test-foldersearch :: type blah3\blah3.txt
blah3
I was able to reproduce the problem. When I specify the directory “D:\tmp\test-foldersearch” in the “Directories” field, Komodo does find all the instances of the string, including those in the two files in the immediate subdirectories:
But when I change the directory to “D:\tmp” in the “Directories” field, Komodo fails to find the instances of the string in the subdirectories now two levels lower:
In other words, Komodo does not appear to be searching beyond one level down.
Changing the Directories up one or even two directories has no effect for me. It still finds all the appropriate strings (and a LOT more since two dirs up is a very full directory). Tried this on both Windows and OSX.
Next steps I’d say would be to:
- Confirm that you can or cannot repro in safe mode
- If you cannot, see if you can discover what setting in the find dialog might effect this (maybe you have multiple directories set? Click the
...button) - If you still can’t find anything, send me your prefs file at careyh@activestate.com and I’ll try to repro with your prefs.
- If you cannot, see if you can discover what setting in the find dialog might effect this (maybe you have multiple directories set? Click the
- If you can still repro in safe mode, try a re-install and
If nothing comes of the above then I’m at a loss. The only thing I can point to then is something wonky with your OS or HD.
- Carey
I’m now not able to restart in safe mode because the new sign-in system is asking me to login, and when I enter my username or email address and the correct password, it always fails, even though I confirmed that I’m able to login to the website https://platform.activestate.com/sign-in using those credentials. I think this is the first time I have tried to use safe mode ever since the change in licensing a while back.
Whaaaaaaaaat? Are you perhaps using your credentials from these forums instead of platform.activestate.com?
- Carey
I definitely was using the correct password for platform.activestate.com, because I copied it from my Firefox password manager, and used it to login to my ActiveState account immediately after using it to try to sign in with Komodo. Anyway, whatever problem I encountered then appears to be gone, because using the same password I’m now able to login to Komodo.
Using Komodo with a safe restart mode, I’m getting the same results that you are (i.e., the recursion is not limited to the first level subdirectories):
But when I again restart using my regular editing mode, I again see the faulty results of the search not going beyond the first level of subdirectories:
I will here attach the log files from both the safe mode and my regular mode:
Hmm, I don’t see any way to attach a TXT file. What is the method we used in the past for attaching Komodo log files? I don’t see any method mentioned in my notes.
@mjross, email your prefs file to me, don’t attach it here and you can send the log files as well. Careyh@activestate.com.
@mjross success! I can repro with your prefs! So weird. I manually deleted any prefs having to do with find and it seems to resolve the issue, which isn’t all that helpful but if you feel so inclined you could try deleting them one at a time to see which one is causing an issue.
I sent you a fixed prefs file back in an email.
Thanks for working on this, and for the new prefs.xml file. I used it to replace my existing prefs.xml (after shutting down Komodo, of course), but unfortunately it did not fix the problem of the Find functionality not looking into the lower-level subdirectories:
@mjross, I think your best bet at this point is reseting your profile and working from there. Even if we isolate what the issue is, it’s not very likely that we’ll do a release to fix the the bug as no one else has come across it.
I agree. Would the steps be: Help > Troubleshooting > Reset Everything ?
@mjross, if you don’t have any toolbox items you want to preserve then yes, otherwise I’d just delete prefs.xml and prefs.xmlc and XRE/extensions and hopefully that does it. That’s the least destructive reset.
Now that I say that though, when you tried the Prefs files I sent you, did you remove the prefs.xmlc file before restarting? If you didn’t, try it again:
- Stop Komodo
- Delete prefs.xml and prefs.xmlc
- put the prefs.xml file I sent you in your profile
- start Komodo
prefs.xmlc is what Komodo actually loads and just syncs it’s state to prefs.xml so use humans can parse it.
@careyh: Thanks for the explanation. As you might imagine, I was not deleting prefs.xmlc and thus the new preferences were not being implemented when I restarted Komodo. So I tried it again, but this time deleting both files, and it fixed the problem of directory searching not being fully recursive.
Unfortunately, even though my custom macros are still present, all of my (beloved and quite numerous) key bindings are not present – which for me would be much more of a problem than the directory searching not working fully.
@mjross, I bet that’s because I loaded your prefs and your customer keybindings schema file wasn’t in my profile so it dropped it. You should be able to find the keybindings file from [your profile]\schemes\name-of-scheme.kkf and drag and drop it on Komodo to get them back.
Let me know if that doesn’t work.
@careyh, I replaced the preferences file with the one that you provided (after deleting the two preferences file I was using before). Then I opened Komodo and reduced the screen size so that I could also see the list of profile files in File Explorer. I then dragged my key bindings file (Admin.kkf) onto the Komodo window (which I think is what you meant by dragging and dropping it), but instead of changing the key bindings it simply opened the key bindings file in Komodo.
GAH, I could have sworn we wrote custom drag’n’drop handlers for all the Komodo file types. Maybe it was just the toolbox. I’d go the janky route then: put Admin.kkf somewhere safe, create a custom keybinding, give it the same name, close Komodo, move the original Admin.kkf in place and start Komodo.