Find (CTRL+F) Suggestions

Noticed a while ago that the find behavior had been slightly changed/improved, previously the find dialog autoclosed after the first match and f3 had to be used to find subsequent matches, now it remains open and the button function changes to find next after the first result.

1. Would it be possible to assign the F3 shortcut key to the find next button in the find dialog, as to maintain better program concistancy and ease-of-use.

2. What about a Find All button to quickly find and select all matches and autoclose the find dialog.

3. Find history/dropdown list in the find dialog, like that which is implemented in the FTP File Search dialog.

4. In line with Find suggestions, i still think regular expression support would be handy, especially if 2 is implemented, only useful to those familar with regex but would be a very powerful feature improvement (both here and in other similar parts of the program)

Originally Posted by DayCuts

1. Would it be possible to assign the F3 shortcut key to the find next button in the find dialog, as to maintain better program concistancy and ease-of-use.

Yeah sure this can be added, you can also press enter with the text box selected to perform a find next.

Originally Posted by DayCuts

2. What about a Find All button to quickly find and select all matches and autoclose the find dialog.

We'll need to work this into a future release as this will require language translations updates. It is possible to use the "mask select" feature on the directory menu to perform this same type of effect.

Originally Posted by DayCuts

3. Find history/dropdown list in the find dialog, like that which is implemented in the FTP File Search dialog.

I'll put this on the todo list for a future version, this could be very useful indeed.

Originally Posted by DayCuts

4. In line with Find suggestions, i still think regular expression support would be handy, especially if 2 is implemented, only useful to those familar with regex but would be a very powerful feature improvement (both here and in other similar parts of the program)

regex is too slow to be used for most areas because the matching is done in real-time and would effect the entire application performance.

granted regex is great for those who know the syntax but currently it doesn't really fit in well with FlashFXP.

I have been experimenting with another pattern matching that is based on unix grep, it's faster than regex and contains a lot more functionality compared to what we use now however there is still a noticeable difference in performance.

Just out of curiosity, but how much slower are you talking? and what flavor were you playing with? (pcre is probably best)... granted it will always be slower than wildcards / string maps, and could get very slow for badly written or overly complex patterns (with lookaround and referencing and such), but for the most part for use in the regular find it shouldn't even be noticable on an intermediate pattern (same pattern in ftp file search would possibly be noticable due to the larger number of items to parse in sequence.

I have several tcl shell scripts and such that i have written and used regex matching in that i have never had a noticable performance decrease with, even when bombarded with data to parse (some times it is even faster as the function can have a significant amount of error checking removed if the regular expression is written well)

In my tests with basic/intermediate expressions i only noticed a max of about 22% speed decrease in the match time, tests were done with 100k lines of data (results were 5.188s vs 3.984s for regex and wildcard respectively). An intermediate/complex regex pattern is obviously going to take longer than a very basic wildcard match, but at a few thousand matches per second (on the slow end) for regex it shouldnt really be that much slower that most users would even notice unless working with large lists. It could actually save time by performing all matching in one run rather than the user performing several in sequence.

For those that are not using a regex pattern it wont make a difference at all as the functions will never even be called.

Not trying to convince you or argue the point, ultimately you will do the neccersary tests and evaluation to see if you think its worth implementing, im just having a hard time seing any significant performance decrease...

Maybe, if for some odd reason you are experiencing performance issues with regex in the flashfxp codebase, it would be a more appropriate feature for the (maybe) future recode.

Originally Posted by bigstar

Yeah sure this can be added, you can also press enter with the text box selected to perform a find next.

Indeed, its just generally easier to use one key sequence under all circumstances than switching, thanks

For most places it would be simply comparing all the patterns against each filename, one by one. However for things like the highlight filter it would need to compare each pattern separately against each filename.

In order to do a proper performance test you need to have a bunch of filename sized strings and perform a search on each one of them separately, rather than running it on say 100k of text.

On my system the existing wildcard matching takes an avg of 0.000454 (second) per comparison. the regex version takes 100x longer per comparison.

We'll really need to be careful on how we add regex support and where we add it because depending on the situation it might cause poor performance and reduce the user experience.

Hmm, i hadn't really concidered some of the more intensive/involved places regex could be used like highlighting and selective transfer rules, but 100x still seems unrealistically slower. You also have to concider that for each wildcard rule you combine into the one regex rule, the difference between the two overall functions gets lower and lower, but anyway.

UNIX style grep would also be great, grep is just another flavor or regex (pcre is the most commonly used), it offers most of the basic functions of pcre (no lookarounds and backreferencing etc) so id say their would not arise many occasions that grep would not be able to do what a user may want (an example of such an occasion would be attempting to match strings that contain repetative words). Given that grep and pcre are both popular forms of regex and perform most of the same basic functions, it also seems strange that their would be such a significant difference between the performances, i mean if your not using non-basic patterns then pcre shouldnt be any slower.

Still failing to understand why your tests have given such huge performance decrease results, when my own applications of pcre standard regex are nowhere near that much slower. (one such shell script actually does recurse a directory and compare filenames to lists of patterns for sorting.. its noticably slower than using a list of wildcard strings but not to that extent).

Anyway, id be just as happy with an implementation of unix style grep.