case insensitive exact content search
Searching in file names is case-insensitive by default. Searching content with c/ is case-sensitive by default.
Intuitively, I'd have expected c/ to also be case insensitive. Adding /i at the end does not turn on case sensitivity as it does for cr/.
broot 1.11.1 on Ubuntu
Suggestions
I see several possible solutions (the one I like most ordered first):
c/could be "smart" by default, like vim withset smartcase: If all chars are lowercase in the search, search case-insensitively. If at least one is uppercase, search case-sensitively. This works very well for me in vim, matches my intuitive expectation and makes it trivial to turn on case sensitive search- if this is not possible,
c/could be case insensitive by default - If none of the above two can be implemented,
c/should at least accept the/iflag thatcr/accepts to turn case-sensitivity off
There are two kinds of content searches:
- exact search, fast but absolutely not tunable, set to
c/by default - regular expression: a little less fast but very configurable, set to
cr/by default
Is there a reason for not using cr/ in your case ? You can even remap it to a one letter prefix if you want.
@Canop thanks for your reply! Using cr/ means that I have to be aware of regex special characters while searching. While not a backbreaking problem, I find this uncomfortable. Also, my search is not iterative, since it only really does what I want once I have added /i at the end. So "iterative search term refinement" is a lot more clumsy:
- enter partial search, e.g.
cr/asdf - append
/i - now I see first actual results
- move cursor left by two characters
- keep refining search
This is much nicer with smartcasing. Smartcasing was also what I intuitively expected c/ to do (being used to it from vim).
Is there any use case where a "smartcased" c/ search would not be wanted?
As to performance, is case-insensitiveness a big performance problem for content search? I'd have though there should be ways to make case insensitive search fast, e.g. lowercasing the searched file contents (should be O(n) I guess, but haven't measured actual performance of lowercasing). I'd be happy to research this, if you think it's a problem.
OK, I understand why you don't find cr/ ideal.
I won't change the existing fast content search c/ but I'll probably add another search engine for easier case insensitive search.