I am loving the new scroll wheel focus feature in 13.10.2, but I discovered, I am unable to paste long querries into the serach box.
Example of a long querry:
FILENAME_0184|FILENAME_0189|FILENAME_0193|FILENAME_0194|FILENAME_0219|FILENAME_0223|FILENAME_0225|FILENAME_0254|FILENAME_0258|FILENAME_0260|FILENAME_0263|FILENAME_0273|FILENAME_0309|FILENAME_0312|FILENAME_0314|FILENAME_0319|FILENAME_0337|FILENAME_0427|FILENAME_0438|FILENAME_0442|FILENAME_0489|FILENAME_0490|FILENAME_0494|FILENAME_0499|FILENAME_0514|FILENAME_0519|FILENAME_0522|FILENAME_0553|FILENAME_0577|FILENAME_0581|FILENAME_0601|FILENAME_0615|FILENAME_0627|FILENAME_0650|FILENAME_0661|FILENAME_0662|FILENAME_0666|FILENAME_0669|FILENAME_0671|FILENAME_0672|FILENAME_0674|FILENAME_0675|FILENAME_0676|FILENAME_0679|FILENAME_0691|FILENAME_0731|FILENAME_0734|FILENAME_0838|FILENAME_0872|FILENAME_0887|FILENAME_0895|FILENAME_0896|FILENAME_0900|FILENAME_0917|FILENAME_0928|FILENAME_0937|FILENAME_0938|FILENAME_0941|FILENAME_0948|FILENAME_0949|FILENAME_0950|FILENAME_0951|FILENAME_0960|FILENAME_0968|FILENAME_0976|FILENAME_0986|FILENAME_0993|FILENAME_0995|FILENAME_1000|FILENAME_1002|FILENAME_1014|FILENAME_1016|FILENAME_106436347517|FILENAME_1047|FILENAME_1074|FILENAME_1116|FILENAME_1118|FILENAME_1123|FILENAME_115238|FILENAME_1143|FILENAME_1151|FILENAME_1175|FILENAME_1179|FILENAME_1186|FILENAME_125324|FILENAME_1243|FILENAME_1251|FILENAME_1252|FILENAME_1253|FILENAME_1254|FILENAME_1259|FILENAME_1295|FILENAME_1314|FILENAME_1319|FILENAME_1321|FILENAME_1333|FILENAME_1353
My workflow requires finding even 300 files from a list and I think this is the only way.
I believe filtering a flat folder view does not have such limits but I would like to be able to use search for it as it may happen across multiple drives/folders.
How is the file list being turned into a long wildcard at the moment?
It’s something that can be done and probably made easier than the way you were using, but exact details will depend on the how the input data looks / where it comes from.
It's not easy because it's all about retrieving basename.differentEXT$ from various sources. I deal with text files containing just some numbers, often with the basename missing, which I need to convert. There are also files where basenames have a different extension (I have a script to find the RAW files based on JPEGs). However, I don't always have the JPEGs, which necessitates a text-based workflow.
In other words, for the search workflow, I manually prepare the pattern in Sublime Text, where I can easily add .ext$| to the basenames using the multicursor.
At other times, I need to search for multiple files across dozens of drives simultaneously, and the UI is quite useful for this.
Moreover, I don't understand why filtering has no limit while the search does.
In practice, the list is more like: FILENAME_0184.EXT$|FILENAME_0189.EXT$|FILENAME_0193.EXT$|FILENAME_0194.EXT$|FILENAME_0219.EXT$|FILENAME_0223.EXT$|FILENAME_0225.EXT$|FILENAME_0254.EXT$|FILENAME_0258.EXT$|FILENAME_0260.EXT$|FILENAME_0263.EXT$|FILENAME_0273.EXT$|FILENAME_0309.EXT$|FILENAME_0312.EXT$|FILENAME_0314.EXT$|FILENAME_0319.EXT$|FILENAME_0337.EXT$|FILENAME_0427.EXT$|FILENAME_0438.EXT$|FILENAME_0442.EXT$|FILENAME_0489.EXT$|FILENAME_0490.EXT$|FILENAME_0494.EXT$|FILENAME_0499.EXT$|FILENAME_0514.EXT$|FILENAME_0519.EXT$|FILENAME_0522.EXT$|FILENAME_0553.EXT$|FILENAME_0577.EXT$|FILENAME_0581.EXT$|FILENAME_0601.EXT$|FILENAME_0615.EXT$|FILENAME_0627.EXT$|FILENAME_0650.EXT$|FILENAME_0661.EXT$|FILENAME_0662.EXT$|FILENAME_0666.EXT$|FILENAME_0669.EXT$|FILENAME_0671.EXT$|FILENAME_0672.EXT$|FILENAME_0674.EXT$|FILENAME_0675.EXT$|FILENAME_0676.EXT$|FILENAME_0679.EXT$|FILENAME_0691.EXT$|FILENAME_0731.EXT$|FILENAME_0734.EXT$|FILENAME_0838.EXT$|FILENAME_0872.EXT$|FILENAME_0887.EXT$|FILENAME_0895.EXT$|FILENAME_0896.EXT$|FILENAME_0900.EXT$|FILENAME_0917.EXT$|FILENAME_0928.EXT$|FILENAME_0937.EXT$|FILENAME_0938.EXT$|FILENAME_0941.EXT$|FILENAME_0948.EXT$|FILENAME_0949.EXT$|FILENAME_0950.EXT$|FILENAME_0951.EXT$|FILENAME_0960.EXT$|FILENAME_0968.EXT$|FILENAME_0976.EXT$|FILENAME_0986.EXT$|FILENAME_0993.EXT$|FILENAME_0995.EXT$|FILENAME_1000.EXT$|FILENAME_1002.EXT$|FILENAME_1014.EXT$|FILENAME_1016.EXT$|FILENAME_106436347517.EXT$|FILENAME_1047.EXT$|FILENAME_1074.EXT$|FILENAME_1116.EXT$|FILENAME_1118.EXT$|FILENAME_1123.EXT$|FILENAME_115238.EXT$|FILENAME_1143.EXT$|FILENAME_1151.EXT$|FILENAME_1175.EXT$|FILENAME_1179.EXT$|FILENAME_1186.EXT$|FILENAME_125324.EXT$|FILENAME_1243.EXT$|FILENAME_1251.EXT$|FILENAME_1252.EXT$|FILENAME_1253.EXT$|FILENAME_1254.EXT$|FILENAME_1259.EXT$|FILENAME_1295.EXT$|FILENAME_1314.EXT$|FILENAME_1319.EXT$|FILENAME_1321.EXT$|FILENAME_1333.EXT$
Unless the files are really named FILENAME_<some number>.<some ext> (in which case you could go for FILENAME_(number1|number2|number3).EXT$, but event that could be too long depending on the number of files), that's probably the quickest solution.
Splitting a list is not convenient and should not be necessary. With the button, I would have to have a predifiened "Find in:" path, which also is not convenient as I switch drives and folders all the time.
I would like to use the convenience of Find UI.
The filename might not always by "FILENAME_some_number" as there might be a typo or a different pattern.
In other words, I would expect FIND to just work with anything I throw at it. I do not understand the 260 chars limitation.
Could you, please, make it possible to paste as much as I want there? If not, could you please explain why?
Using the Find UI seems difficult due to the "limitation" you encountered.
I tend to think that the best option is what @lxp proposed : a multi-pass search all feeding in the end a collection :
I've never tried that, but at first sight, it looks like something scriptable (meaning the script would take the whole list as an input, will do the split work for you, launch the Find commands and consolidate the result in one collection).
Computers history is made of limitations (# of available colors, screen resolution, drive sizes, max size of file on drive, max depth of a path to name a few) ... due to the fact that a computer uses a limited set of resources, many things get limited (often by the amount of memory allocated to store them, sometimes by the developpers for other reasons). At some point, we all have to live with it and find workarounds when possible.
What is currently combining them into one long string?
My thought is that you could change that to generate a filter expression which would do the same thing. Or have some script code in Opus which does it.
The whole process can probably be streamlined and automated to the point that you just click a button, select a file (or it reads the clipboard) and it starts showing you the results without even having to interact with the Find panel.
But how it will work will depend on the details, since we don't have any information on where the list of names is coming from at the moment.
Leo, I described everything. It is not something that can get automated, like I told you.
The list is mostly created manually in a text editor because I receive the file names from differnet people. One send JPG previews and I have a script to find the corresponding RAW files, but that is not a rule. Sometimes they present the file names as an image in an email and I have to OCR it and manually arrange it in Sublime Text editor, sometimes I get just the numbers, sometimes filenames and numbers, which also forces me to create the list manually. It's not always 300 files, it can be less, but enough to not fit into the Find input field.
Besides, I also need to search across many drives and folders. I don't want to have buttons for that, I want to use the Find UI and have everything easily configurable and managable.
Just please let me paste as much of the text as I want in the Find UI. There should be no reason there is some kind of low limit there.
The filter expression does not work across multiple drives and folders. Also, it takes time to display the flat folder view in the first place. Find is a much faster solution for my usecase.
I talked with a friend who said the issue is about how much memory we set aside in advance—like whether we set aside enough room for 260 characters or more. Allocating a small amount like 260 characters is quicker and easier, usually done in one step. But if we need a lot more space, it gets more complicated and can slow things down.
However, the difference isn’t as huge as one might think. While allocating more memory can be a bit slower because of the extra steps involved, it's generally not a big deal unless the program really needs to run in real time.
I think we should handle this through the code rather than making users deal with it. We could add a “slow mode” option if performance becomes an issue, letting users choose more functionality over speed when they need it.
I don't know if it's just me, but I can't imagine typing (or pasting) +300 characters into that small box control, only to realize I have to change some of them in the very beggining! :).
And I don't think that has anything to do with how much RAM I have either.
There should be a better way...
A bit outdated, but this might help.
So you have a text file with a list of filenames in it?
You absolutely can automate turning that into a filter which will work with the Find panel.
You can still use the Find UI if you want to. The automation could just build a filter which matches all the filenames and can be pasted into the Find panel's Advanced mode. You could then specify whichever drive(s) you want to search and other settings.
Edit controls in Windows have a hard limit at some point, and each has a defined limit which is less than or equal to that, so the approach you are using will not always be possible. While we could increase the limit on that control somewhat, there are much better ways to match a large list of files than turning it into a huge wildcard expression by hand.
If you want help with the approach I've suggested, please share an example file list (e.g. text file) so we can make sure anything we write works with the data in the format you will have it.
I came from Mac, where in Forklift it was possible to paste long wildcard expressions, without the need for breaking it down. I also used that syntax in bash, so it was natural for me that everything works that way.
Now I understand I should use the advanced mode with edit as text and just use a different query syntax. While it's an extra step it's something I can easily live. I can prepare the script for creating advanced queries myself, thanks!
