[BUG]: ext:/extension: works inconsistently with wildcard:

[DerekZiemba]

Wanted to use the advanced wildcard matching that lets you use # for numbers.
Was stumped as to why

wildcard:ext:m#v

was not working.
Turns out, it apparently only works if ext: is fully spelled out as extension:

This behavior should be documented or

ext:

should be made to behave consistently.
Relevant documentation:
viewtopic.php?t=10860#wildcard
viewtopic.php?t=10176#ext
viewtopic.php?t=10176#extension

image.png (155.34 KiB) Viewed 3514 times

[DerekZiemba]

Also,

wildcard:

breaks on

extension:

query if there isn't any actual wildcards.
There appears to be a lot of gotchas here.

image.png (64.47 KiB) Viewed 3512 times

[void]

ext: is not a standard property search function.
ext: doesn't support the wildcard search modifier and has it's own syntax.
ext: takes a semicolon (;) delimited list of whole extensions.

extension: is a standard property search function.
extension: does a partial search against the filename's extension.
This supports the standard function syntax, such as semicolon (;) delimited lists as OR lists.

The wildcard: search modifier overrides semicolon delimited lists.
The wildcards: and regex: modifier treat ; as literal.
This was done because regex has its own OR list syntax.

I wanted to keep the same behavior between wildcards: and regex:
However, since wildcards cannot support lists, and I am already supporting filename wildcards (eg: name:so*;ta* ) I will change the behavior of wildcards: to allow ; lists.

[DerekZiemba]

I wanted to keep the same behavior between wildcards: and regex:
However, since wildcards cannot support lists, and I am already supporting filename wildcards (eg: name:so*;ta* ) I will change the behavior of wildcards: to allow ; lists.

You have solid reasoning as to why it didn't work as expected. It's just unclear there's differences between

ext:

&

extension:

with both being documented on the "Search Functions" page viewtopic.php?t=10176#ext. Which gives the impression both are functions.

I was unaware one was a function & the other a property. It's still unclear

extension:

behaves different. Even re-reading it now, the takeaways I get are essentially:

• ext:
  automatically always allows for
  *
  &
  ?
• extension:
  must be the safe/fallback way if for some reason one doesn't want
  *
  &
  ?
  to do wildcard matching? (I would find it weird, but this is how I'd rationalize if I was just reading through quick).
• I'd still see no reason I can't just tack on `wildcard:` to either of them to get the advanced wildcard matching.

Going forward, I will assume any param matching a column heading is a property, But I'm unsure that's a safe assumption?

My opinion: All properties should behave the same way as all other properties & all functions should behave the same as all other functions. That is to say I'm against special casing some properties to allow lists / changing behavior between wildcards: & regex:.

It sounds like you're going to allow lists for all properties? That sounds nice actually but I'm unclear as to what behavior you wanted to keep the same between wildcard: & regex:. I'm assuming something to do with quoting? I always wrap my regex expressions in quotes just to be safe. And for wildcard expressions I just always assumed quotes would probably throw it off, so never tried - instead using * for space bcus never can be sure what some file is using for spacing ( \s_-, camelcase, kebab, Title, etc.)

[void]

ext: was from Everything 1.4, before I had ; lists and extension:
It was designed for filters, for example the video filter:

Code: Select all

ext:3g2;3gp;3gp2;3gpp;amv;asf;asx;avi;bdmv;bik;d2v;divx;drc;dsa;dsm;dss;dsv;evo;f4v;flc;fli;flic;flv;hdmov;ifo;ivf;m1v;m2p;m2t;m2ts;m2v;m4b;m4p;m4v;mkv;mp2v;mp4;mp4v;mpe;mpeg;mpg;mpls;mpv2;mpv4;mov;mts;ogm;ogv;pss;pva;qt;ram;ratdvd;rm;rmm;rmvb;roq;rpm;smil;smk;swf;tp;tpr;ts;vob;vp6;webm;wm;wmp;wmv

Internally, the extensions are stored backwards (mp4 => 4pm) and sorted.
Then Everything can do a quick extension check by reading filenames backwards.



extension: is flagged as a "filename" property search.
filename property searches allow ? and * wildcards.

I'd still see no reason I can't just tack on `wildcard:` to either of them to get the advanced wildcard matching.

wildcards: changes the syntax a lot.
\ becomes an escape character.

Going forward, I will assume any param matching a column heading is a property, But I'm unsure that's a safe assumption?

Correct.
There's one exception:
Path => pathpart

My opinion: All properties should behave the same way as all other properties & all functions should behave the same as all other functions. That is to say I'm against special casing some properties to allow lists / changing behavior between wildcards: & regex:.

Allowing ; lists would break some functions where ; should be treated literally.
For example:

content:&

I never want ; lists with content:
You can assume all property search functions support ; lists.

regex: and wildcards: are precision search modifiers. -What you search for is treated literally.
With regex: I assume the user knows what they are doing and will never want ; to mean OR.
regex: will treat ; literally.
For example:

regex:name:^filename;with;semicolons.txt$

I never want this to match filename OR with OR semicolons.txt

wildcards: was implemented the same way as regex:
I would like to treat these both as searching for content.
I refer to wildcards: as content wildcards.

It sounds like you're going to allow lists for all properties?

This is already the case for property search functions.

That sounds nice actually but I'm unclear as to what behavior you wanted to keep the same between wildcard: & regex:. I'm assuming something to do with quoting?

I need to review this more..
There's issues with handling \;
For now, I will keep wildcard: behavior the same as regex:
Internally, wildcards: and regex: are both handled exactly the same way. regcomp => wildcards_comp, regexec => wildcards_exec
There's similar syntax between both of them.
They both expect "content" data. (data that can contain any character sequence, including ; )

I am thinking of adding another search modifier semicolonlist: (maybe just list: ) to give the user full control over the behavior.

For now, please use regex: for the most control.

-or-

Use wildcards: with everything search syntax.
For example:

Code: Select all

wildcards:extension:m#v | ext:jpg;png
wildcards:extension:<m#v|jpg|png>

I always wrap my regex expressions in quotes just to be safe.

Only spaces and > will break a regex term in Everything 1.5.
Everything will treat | literally.

for wildcard expressions I just always assumed quotes would probably throw it off, so never tried - instead using * for space bcus never can be sure what some file is using for spacing ( \s_-, camelcase, kebab, Title, etc.)

Spaces, > and | will break a wildcard term.