Option for case-insensitive search

[dumblob]

Currently the search is a perfect match (thus also case sensitive). I'd like to have an option to switch case insensitive matching on or even the "combination" of case (in)sensitive matching - i.e. when the searched term contains at least one upper letter, do a case sensitive search and in other cases do a case insensitive match (I use this "combined" matching all the time in vim).

Hm, thinking about search functionality improvements, maybe support for wildcards * and ? or even a fuzzy match (but this would require an external library for nearly no benefit) or at least support for "multi partial match" search (i.e. split the searched string by [[:blank:]]+ into words and then try to find the first word in the text, if found, start searching for the second word from the position of the character right behind the last character of the first match, if found, start searching for the third word from the position of the character right behind the last character of the second match, etc. - in other words a wildcard matching *word1*word2*word3*) would be very handy (regexes are too precise and not so concise).

Any comments on these suggestions? Of course, the exact behaviors should be then described in lf -doc.

[gokcehan]

For reference, these are called ignorecase and smartcase in vim. To me smartcase makes the most sense without any disadvantages. I think we can change the current implementation to smartcase or at least make smartcase the default if we're going to introduce an option for this.

For the rest of the suggestion, you mention three alternatives. If you ask me, (1) fuzzy matching is too imprecise for regular searching. It is mostly aimed to save keystrokes when matches are displayed as an interactive list so even if we implement something like incsearch as in vim, it wouldn't feel the same. We can use (2) regular expressions from the standard library which probably requires only a few lines of change. Go implementation is guaranteed to work in linear time and is well documented already. Or we could use (3) improved regular expressions so some searches would be more concise (e.g. *word1*word2*word3* instead of .*word1.*word2.*word3.*) which I think is used in find -name somehow.

I'm in favour of option (2), option (3) is a close second, and I think we should skip option (1) for this issue. For me there are a few important considerations. First, users should not be required to learn something new. If I'm not mistaken, vim already have multiple regular expression syntaxes (i.e. magic), which are different than those two implemented in unix tools (basic and extended syntaxes), which are different than perl regular expressions. When there is such a mess, advanced features tend to be ignored more often. Second, it should be easy to implement and maintain so I think it is better to stick with an existing implementation rather than implementing something from scratch. Option (2) is already available in the standard library. I need to check if there is something we can use for option (3).

[dumblob]

I would advocate for the option (3). Actually it seems dead simple to convert a wildcard to a Go RE2 regex - see e.g. https://github.com/blevesearch/bleve/blob/master/search/query/wildcard.go .

Also I would rather avoid direct regex input as (a) it's verbose, (b) it won't bring basically any benefits (in my whole life I've come across just about 4 file name matching issues which were too complex for wildcards and needed to be solved by some small additional logic), but mainly (c) it's confusing for users (as it was already many years ago: Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. by Jamie Zawinski).

[gokcehan]

I have been doing some reading. I was thinking regular expressions and wildcards (or globbing) are related but I guess they are not. It looks like wildcards are much simpler and aimed for matching filenames whereas regular expressions are more complicated aimed for matching any kind of text. I think it makes sense for us to use wildcards. I like the idea of keeping it simple.

That code you linked tries to use regular expressions to implement wildcards but there already seems to be a wildcard implementation in the standard library:

https://golang.org/pkg/path/filepath/#Match

[dumblob]

there already seems to be a wildcard implementation in the standard library:

https://golang.org/pkg/path/filepath/#Match

Didn't notice. That's great!

[gokcehan]

All three options mentioned here are now implemented. I have enabled ignorecase and smartcase by default. Closing this issue now.