Unable to find files and folders with an '!'

[iycgtptyarvg]

Today I did a search for all files in a directory which had an '!' in the name. I use the fantastic 'filter as you type' feature. To my great surprise no files were returned. On inspection I saw there were 2 files of the format <name>!.<ext>
Doing a 'full search' also didn't show any files while there really are 2 files with an '!' in them.

Is this a bug or am I doing something stupid?

[highend]

! is interpreted as a NOT in the filter as you type as it seems. That should probably change

By "full search" you mean the interface that is invoked by Ctrl + f?

Show a screenshot of it...

[iycgtptyarvg]

Yes, with <CTRL+F>. See screenshot.

XYplorer !.png (17.22 KiB) Viewed 976 times

[highend]

You probably have
Configuration | Find and Filter | Find Files & Branch View | Find Files | Enable extended pattern matching
checked.

In that case (and if you want to keep it) you need to enclose the ! in []

[admin]

Wow, that was a surprise. I see a combination of a bug and some doubtful behavior. Here is the change log:

Code: Select all

    ! Quick Search: A leading "!" was still seen as Boolean operator if "Enable 
      extended pattern matching" was off. Fixed.
    * Find Files & Branch View | Find Files | Enable extended pattern matching: 
      Now a single "!" is not seen as unary Boolean NOT operator even if the 
      setting is on.
    * Live Filter Box: Now a single "!" is not seen as unary Boolean NOT 

So, in the next version typing a single ! into the live filter box ('filter as you type') will work as expected (show all items containing a !).

BUT: Contrary to Find Files and Quick Search, Visual Filters (and Live Filters, which are technically the same) are hard-coded to allow "extended pattern matching", so when you type "!a" (w/o quotes) you will get all items NOT containing an a. The only way to get all items containing "!a" is the pattern "[!]a". Not totally satisfying.

Questions:
a) Should Visual Filters / Live Filters also get an option to disable extended pattern matching???
b) (or) should Live Filters always internally disable extended pattern matching???

[admin]

Decided for this:

b) (or) should Live Filters always internally disable extended pattern matching???

Makes total sense since it makes Live Filters behave like Type Ahead Find in that respect (treat ! and # as characters).