function "count:" sets the count limit for the entire search text
I would like to suggest a related new function - "orcount:"
this would set the count limit for each OR (|) search term
the task I'm wanting to solve in Everything is this:
I find a compilation of music tracks on the Internet, and I'd like to
know which tracks I already have and don't have as mp3s etc. ...
Using notepad++ and regex I can convert any listing into the format:
<artist - song> | <artist - song> | <artist - song> ...
I have many duplicate tracks in my 'database', which is why I need 'count'.
Another relatively efficient approach would be to paste each track into the search box
one by one using a script/app which can paste the next line from the clipboard.
I have such a working script (using AutoHotKey) which is invoked with Ctrl-J.
BUT
Everything, it seems, will not allow misc. keyboard shortcuts to be used in the
search box to paste data, apart from Ctrl-V.
Perhaps this limitation could be addressed as well.
Thanks for any consideration of this request.
set 'find count' for each OR <term>
Re: set 'find count' for each OR <term>
Thank you for your feedback and suggestions Happylad,
I will consider an orcount: search function.
ES (the command line interface to Everything) might be helpful:
del out.txt
ES.exe count:10 artist - song1 >> out.txt
ES.exe count:10 artist - song2 >> out.txt
ES.exe count:10 artist - song2 >> out.txt
Would append the full path and filename for each result to out.txt (up to 10 results for each call).
Everything processes key presses in the main message loop.
You will need to 'post' (not send) your key presses to the main Everything UI window (classname: EVERYTHING).
Everything 1.5 alpha adds support for sending key presses to the search box / result list.
I will consider an orcount: search function.
ES (the command line interface to Everything) might be helpful:
del out.txt
ES.exe count:10 artist - song1 >> out.txt
ES.exe count:10 artist - song2 >> out.txt
ES.exe count:10 artist - song2 >> out.txt
Would append the full path and filename for each result to out.txt (up to 10 results for each call).
Everything processes key presses in the main message loop.
You will need to 'post' (not send) your key presses to the main Everything UI window (classname: EVERYTHING).
Everything 1.5 alpha adds support for sending key presses to the search box / result list.
Re: set 'find count' for each OR <term>
Thank you for your positive response.
> ES (the command line interface to Everything) might be helpful:
> del out.txt
>ES.exe count:1 artist - song1 >> out.txt
I'll keep ES in mind, but as regards my current task this approach will not always be practical.
Why? Because, when dealing with obscure 'artist - song' tracks there can be discrepancies
in the spelling of 'artist - song' that requires the search term to be modified before a match
can be found - i.e. one edits (fiddles about with) the artist - song in the Everything search box.
> You will need to 'post' (not send) your key presses to the main Everything UI window...
Thanks, but I've solved my problem (using 1.4 on Windows 10) by simply running the AHK script as Administrator!
So currently I'm feeding my songs to Everything one by one from the clipboard, which might contain, for instance:
count:1 Shout Bamalama - OTIS & THE SHOOTERS
count:1 I've Been A Bad Bad Boy (Alt.Vers.) - KINGBEATS
count:1 Mad Man - JIMMY WAGES
count:1 Lookie Lookie - K.C.GRAND
count:1 Funnel Of Love - WANDA JACKSON
count:1 Nothin' Shakin' - BILLY FURY
produced with Regex in Notepad++ from an old post in https://4578oldies.blogspot.com/
I've set the Sort in Everything to Descending File Size in case I use what's found to build a playlist
(not guaranteed of course, but it's assumed the bigger the audio file the better the sound quality).
While doing this another fanciful "Suggestion" occurred to me:
A toggle button on the UI form which turns off and on the clearing of Results when the search term changes.
Yet another suggestion:
Within each explicit <...> term or once for an entire search term
be able to specify a 'reference' that will prefix each result line for that search term
for instance:
<ref:3. Mad Man - Jimmy Wages> | <ref:4. Lookie Lookie - K.C. Grand> | ...
Thanks for taking the time and effort to read this post (, David?).
Cheers!
> ES (the command line interface to Everything) might be helpful:
> del out.txt
>ES.exe count:1 artist - song1 >> out.txt
I'll keep ES in mind, but as regards my current task this approach will not always be practical.
Why? Because, when dealing with obscure 'artist - song' tracks there can be discrepancies
in the spelling of 'artist - song' that requires the search term to be modified before a match
can be found - i.e. one edits (fiddles about with) the artist - song in the Everything search box.
> You will need to 'post' (not send) your key presses to the main Everything UI window...
Thanks, but I've solved my problem (using 1.4 on Windows 10) by simply running the AHK script as Administrator!
So currently I'm feeding my songs to Everything one by one from the clipboard, which might contain, for instance:
count:1 Shout Bamalama - OTIS & THE SHOOTERS
count:1 I've Been A Bad Bad Boy (Alt.Vers.) - KINGBEATS
count:1 Mad Man - JIMMY WAGES
count:1 Lookie Lookie - K.C.GRAND
count:1 Funnel Of Love - WANDA JACKSON
count:1 Nothin' Shakin' - BILLY FURY
produced with Regex in Notepad++ from an old post in https://4578oldies.blogspot.com/
I've set the Sort in Everything to Descending File Size in case I use what's found to build a playlist
(not guaranteed of course, but it's assumed the bigger the audio file the better the sound quality).
While doing this another fanciful "Suggestion" occurred to me:
A toggle button on the UI form which turns off and on the clearing of Results when the search term changes.
Yet another suggestion:
Within each explicit <...> term or once for an entire search term
be able to specify a 'reference' that will prefix each result line for that search term
for instance:
<ref:3. Mad Man - Jimmy Wages> | <ref:4. Lookie Lookie - K.C. Grand> | ...
Thanks for taking the time and effort to read this post (, David?).
Cheers!