Ignore punctuation + Match path - Everything ignores backslash for matching

[aviasd]

Hi,
When match path and ignore punctuation is enabled, everything will ignore backslash and continue matching after \
for example:
When querying for: movies

Code: Select all

c:\movie\subtitles\somefile.srt

Is also matched.
I may continue typing moviesubtitle and the match is persistent.
Is this by design?
If so, I think it should be noted Here
Edit: It is noted now in the help link above. Was it always there?

[void]

Everything ignore all unicode characters with the punctuation class.

This includes \ and / for full paths.

Updated: Ignore punctuation.

Note: The nopunc: search modifier can be used with other search functions, such as title:, subject:, artist:, album:, content: etc...
nopunc: is not specific to filenames.

Edit: It is noted now in the help link above. Was it always there?

I added the hint as soon as I saw your post.
I looked into possible solutions, such as treating \ and / differently (not as punctuation).
However, I feel the rules for ignore punctuation should be simple:
Unicode characters with the punctuation class are treated as punctuation.

This can be a curse or a blessing:
nopunc:c:windowssystem32driversetchosts matches C:\Windows\System32\Drivers\ETC\hosts

Another note: punctuation you specify in your search will match punctuation in the filename. (in other words, punctuation in your search is not ignored)
eg: The search for movie\s will only match movie\s (and not movies)

Maybe I can help with improving path matching for you with Match Path disabled under the Search menu..
Is there a reason for using Match Path under the Search menu? Can you give an example of how you use this setting?

[aviasd]

Edit: It is noted now in the help link above. Was it always there?

I added the hint as soon as I saw your post.

Ah thanks, thought I was getting senile there..

This can be a curse or a blessing:
nopunc:c:windowssystem32driversetchosts matches C:\Windows\System32\Drivers\ETC\hosts

Yeah, that's what I thought, it's a nice feature but was a bit surprising.

Another note: punctuation you specify in your search will match punctuation in the filename. (in other words, punctuation in your search is not ignored)
eg: The search for movie\s will only match movie\s (and not movies)

That's good to know.. (It's on by default here)

Maybe I can help with improving path matching for you with Match Path disabled under the Search menu..
Is there a reason for using Match Path under the Search menu? Can you give an example of how you use this setting?

Well, match path option is enabled on all my machines by default since I first discovered everything ( I think since everything 1.2 )
It's so integral in my flow that I had to stop and think about how I use it
Match path allows me to be quick and messy without planning ahead

For example:
Say I want to find C:\Windows\System32\Drivers\ETC\hosts

I start by typing hosts - 119 results
I know it's somewhere in windows\system32 so i type system and there it is. Don't need to type anything else, don't need to prefix system with "\". easy.

Another example:
I want to watch a nice series, let's say Futurama but I don't know which episode I'm on.
I start typing futurama and get heaps of non-relevant files.
I know it's under the series folder so I type series\.
Now it's better and looking at the results, I remember that I was on season 2.
I see in the results that the folder name is something like "futurama season s02 ...." so i just type s02 ( Part of the folder name) and now I see what I want.

I know it may sound like a roundabout method for some people but it happens so quickly for me that I don't even have to think about it.
With match path disabled, I could not get partial folder names so easily and would have to invest some time thinking on how to "articulate" what I want...

Hope that explains it..

[therube]

Match Path under the Search menu? Can you give an example of how you use this setting?

.
.

Code: Select all

/Jethro Tull/Thick as a brick-01.mp3
/Jethro Tull/Thick as a brick-02.mp3
/Jethro Tull/Thick as a brick-03.mp3

/Jethro Tull - Thick as a brick/01.mp3
/Jethro Tull - Thick as a brick/02.mp3
/Jethro Tull - Thick as a brick/03.mp3

audio: thick as a brick

Without Match Path, 01, 02, 03.mp3 wouldn't be found.

audio: jethro tull

Without Match Patch, nothing would be found.

[void]

Thank you for the usage examples.

I'll look into ways to improve path searching.

[aviasd]

Thank you for the usage examples.

I'll look into ways to improve path searching.

It may be difficult because right now with match path enabled, typing what folder you want is the most straightforward way - you don't need to add any special characters or specify anything special to match the path.

What can be the alternatives?
For now , to replicate match path I need something like:
hosts path:<c: windows etc>

I've tried:
Hosts path:windows**etc
doesn't seem wildcard matching is working there.

There's also
hosts ::path: windows etc

But that's a tad annoying to type.

I think from all of the above probably this would be the most intuitive to switch to:
Hosts path:windows**etc

And maybe shortening with a p: macro, But still much more typing than the original...

I don't have a solution here, just throwing in my opinion to the mix.

[void]

Thanks for the feedback aviasd,

There's \: in the latest Everything alpha

(It is undocumented as it is experimental)

For example:

hosts \:windows \:etc

The extra typing of two characters is still a pain..

I'm considering an option to allow a single slash to enable match path, eg:
hosts win\ et\
-or-
hosts \ndows \tc
-This will break some useful searches when you want to match the start of filenames.


There's also:
*\hosts
this will find files exactly-named hosts. Unfortunately, it finds files anywhere..

path:windows**etc

The entire sub-path is matched, this would only match filenames ending with etc
It matches:
C:\Windows\System32\drivers\etc
E:\Windows\System32\drivers\etc
F:\backup\2021-05-10\Windows\System32\drivers\etc

path: is not needed when using **
** implies path matching.

For example:
hosts windows** etc**

You could already do the same with:
hosts \windows \etc

windows**etc\hosts

What about a second search bar to search the path?

[aviasd]

Hi,
Sorry for the delayed response...

Thanks for the feedback aviasd,

There's \: in the latest Everything alpha

(It is undocumented as it is experimental)

For example:

hosts \:windows \:etc

The extra typing of two characters is still a pain..

That's a good idea, I've tried it - as a workaround it's good as most of my searches I usually know the start of folder name so \folder can be used, and when I'm are not sure \: is quicker than path:.

I'm considering an option to allow a single slash to enable match path, eg:
hosts win\ et\
-or-
hosts \ndows \tc
-This will break some useful searches when you want to match the start of filenames.

I see, maybe an option to include both types of results would be acceptable? or a multi-toggle option for the current state, path matching, or both ? (0,1,2)

There's also:
*\hosts
this will find files exactly-named hosts. Unfortunately, it finds files anywhere..

Yep, this one is not good for this scenario

path:windows**etc

The entire sub-path is matched, this would only match filenames ending with etc
It matches:
C:\Windows\System32\drivers\etc
E:\Windows\System32\drivers\etc
F:\backup\2021-05-10\Windows\System32\drivers\etc

path: is not needed when using **
** implies path matching.

For example:
hosts windows** etc*

You could already do the same with:
hosts \windows \etc

yes, but hosts windows** etc* allows partial matching
i.e: hosts **wind**et**
BTW:
Typing this search as hosts$ **windo**et**, is working quite good for me.
it only needs a qualifer for what is the last component ( in the above example - the dollar sign $ )

What about a second search bar to search the path?

That's a good idea as well with the added benefit of having stacking filters to filter folders without having any specific syntax and without enabling the match path globally, but I wonder how intuitive will it be for a new user ( switching back and forth )
Although, on a second thought, maybe it'll be more intuitive for a new user... I dunno

I'm considering an option to allow a single slash to enable match path, eg:
hosts win\ et\
-or-
hosts \ndows \tc

I would say that I like this idea the most, and I'll probably use it in a nonbreaking fashion in case it's added ( i.e matching both partial folder names and matching the start of filename...
...(although using ^ has already become the new standard for me )

[void]

Everything 1.5.0.1262a adds another option to the match_path_when_search_contains_path_separator2 ini setting to match path and trim the single leading or trailing path separator (\) or (/)

To match paths with a single \ or / and ignore the \ or /:

• In Everything, type in the following search and press ENTER:
  /match_path_when_search_contains_path_separator2=2
• If successful, you should see match_path_when_search_contains_path_separator2=2 in the status bar for a few seconds.

The path separator is only removed if there is only one.
For example: \dows will match dows anywhere in the path (the leading path separator is removed).
For example: et\ hosts will match et anywhere in the path (the trailing path separator is removed).
For example: etc\hosts will match etc\hosts in the path (not a leading or trailing path separator, path separator is kept).
For example: \downloads\ will still match \downloads\ in the path (more than one path separator, path separators are kept).


I experimented with options to treat \ as **\** or *\*
However, this means the order of terms is important. (not sure it would be useful?)
For example: indo\et\hosts => **indo**\**et**\**hosts**

[aviasd]

The path separator is only removed if there is only one.
For example: \dows will match dows anywhere in the path (the leading path separator is removed).
For example: et\ hosts will match et anywhere in the path (the trailing path separator is removed).
For example: etc\hosts will match etc\hosts in the path (not a leading or trailing path separator, path separator is kept).
For example: \downloads\ will still match \downloads\ in the path (more than one path separator, path separators are kept).


I experimented with options to treat \ as **\** or *\*
However, this means the order of terms is important. (not sure it would be useful?)
For example: indo\et\hosts => **indo**\**et**\**hosts**

Really cool!
What you mentioned is in fact how I tried to query
I.E when experimenting I tried: win\et\hosts before reading carefully your posts but that did not yield what was expected.
**win**\**et**\**hosts** Did

I think for me it makes sense to search for paths like the above ( indo\et\hosts ), which conforms to cd in zsh. I.E: cd /us/loca/sbi <tab>

Having path matching conform to order has it's merit IMO, specifically when you know part of the path to reach the file in question.

For example:

Another example:
I want to watch a nice series, let's say Futurama but I don't know which episode I'm on.
I start typing futurama and get heaps of non-relevant files.
I know it's under the series folder so I type series\.
Now it's better and looking at the results, I remember that I was on season 2.
I see in the results that the folder name is something like "futurama season s02 ...." so i just type s02 ( Part of the folder name) and now I see what I want.

this could be written much more conveniently as
serie\futu\s02\

Also searching for
win\sys\et\hosts
Should be understandable to every sys-admin imo even if he doesn't know about the feature..

Right now I have to type the query with spaces which is ok, but could be better. That is:
win\ sys\ etc\hosts


I think the above is clearer...

[void]

Everything 1.5.0.1263a adds more options to match_path_when_search_contains_path_separator2.

/match_path_when_search_contains_path_separator2=3

will replace \ with *\*
\\ is replaced with **\**

Examples:
win\\hosts
win\32\drive\et\hosts


/match_path_when_search_contains_path_separator2=4

will replace \ with **\**

Examples:
win\hosts
win\32\hosts
win\32\et\hosts


Note: /match_path_when_search_contains_path_separator2=3 or /match_path_when_search_contains_path_separator2=4 doesn't work with regex yet and there might be other quirks when combined with other search options.

I have also improved path matching performance.
Searching for paths should be at-least 2 times faster.

Everything will also now treat / and \ as the same for most path searches (when match diacritics is disabled).

[aviasd]

Note: /match_path_when_search_contains_path_separator2=3 or /match_path_when_search_contains_path_separator2=4 doesn't work with regex yet and there might be other quirks when combined with other search options.

I have also improved path matching performance.
Searching for paths should be at least 2 times faster.

Everything will also now treat / and \ as the same for most path searches (when match diacritics is disabled).

Sorry for the long delay in responses.

I've tried /match_path_when_search_contains_path_separator2=4. it does produce the expected result which is very nice...

My actual searches are now evaluated as **win**\*32**\**hosts

The problem is - This kind of search is very hoggy in CPU resources ( See the attached picture )
This actually maxes out my 24 core CPU and makes the GUI (even typing) becomes quite sluggish until the query is complete.
Is it maybe because it concats path+file to create a full path (no specific index)? I dunno.

For the feature to be used on a regular basis I think the performance issue should be fixed, I don't like seeing/using a slow everything.

For the feature itself - it's great - From the previous example:

Code: Select all

futur\02\08

Now finds exatly what I want:

Code: Select all

[truncated]...Futurama\Season 2 S02\Futurama.S02E01.A.Flight.to.Remember.720p.HULU.WEB-DL.AAC2.0.H.mkv

Also in terms of quirks - this feature does not work when Match path enabled (should be disabled before using)
I'll experiment more and report.

[void]

Thank you for the feedback aviasd,

The problem is - This kind of search is very hoggy in CPU resources ( See the attached picture )

What search options do you have enabled under the Search menu? -with all search options disabled, the search should be instant (with little CPU usage).
-This is most likely caused by a bug with comparing the root folder name.. I am working on a fix.

Have you disabled fast_partial_path_search?

Also in terms of quirks - this feature does not work when Match path enabled (should be disabled before using)

I'll look into an option to enable the **\** feature when match path is enabled.

[aviasd]

What search options do you have enabled under the Search menu? -with all search options disabled, the search should be instant (with little CPU usage).
-This is most likely caused by a bug with comparing the root folder name.. I am working on a fix.

Have you disabled fast_partial_path_search?

Ignore white space and ignore punctuation were enabled - both of which affect performance. I tried to check each independently and both of them spike the CPU higher than 50%. When both disabled the performance is normal again.

I'm not using match diacritics but when I enabled it to test - I also saw a spike in CPU.

fast_partial_path_search is enabled here (1)

The performance spike is not affected differently at any place of the query.
IE:
Starting to type

Code: Select all

fut<cursor>

2000 results
Vs. typing:

Code: Select all

fut\02\ben<cursor>

30 results at this point

- Both of the above queries have the same CPU spike.

BTW: I'd like to point out again how much this feature is great (/match_path_when_search_contains_path_separator2=4)- I've been using it for a couple of days now and finding stuff have never been easier for me...

[void]

Thank you for your feedback aviasd,

Ignore white space and ignore punctuation were enabled

These options would cause the performance you are seeing.
I have only added an optimized path for Match Case.

Without this optimized path, Everything is searching with wildcards **fut**\**02**\**ben** which is very CPU expensive.

I will consider adding an optimized path for ignore whitespace and ignore punctuation. (2^^9 functions to handle all possible search options)

I have changed match_path_when_search_contains_path_separator2 to path_search_type in Everything 1.5.0.1264a.

For \ to **\**, please try /path_search_type=2

match_path_when_search_contains_path_separator2 is pending removal. (It will probably stay for backwards compatibility)

path_search_type should now work when Match Path is enabled from the Search menu.

Everything 1.5.0.1264a also fixes a crash when using /path_search_type=2 and matching roots containing path separators.

[aviasd]

I will consider adding an optimized path for ignore whitespace and ignore punctuation. (2^^9 functions to handle all possible search options)

Yes, I see how this feature can become a headache. Thanks for your consideration.

path_search_type should now work when Match Path is enabled from the Search menu.

Confirmed.

I think it worthwhile noting in path_search_type that the order matters ( For new users )

I.E:
fut\S02\ben

Is not the same as
S02\fut\ben

[aviasd]

Hi

There's an issue with /path_search_type=[1|2]

When setting /path_search_type=1 for example, Searching from another app - In my scenario Total Commander with Everything search enabled,
The search will yield results from folders whose name contains the folder name being searched

For example:
I have this tree:
Root:c:\projects
Inside root:
proj1
proj1.tmp
proj1.bck

Now, When I go into c:\projects\proj1 inside Total Commander, and open search (Alt+F7) and search for a file, let's say - common
I get results also from proj1.tmp and proj1.bck ( as well as c:\projects.orig\proj1)
I understand why this query gets translated into multiple nonrelevant folders with the new option - but it prevents searching for an exact path.

when reverting to /path_search_type=0 I get the correct results (Only results from within c:\projects\proj1)

I could replicate the results given by TC, inside Everything using the query:

Code: Select all

path:c:\projects\proj1 common

TLDR: With the new options - One cannot search for files using exact path search (Which affects some integrations with other apps)

[void]

Thank you for the feedback aviasd,

Everything 1.5.0.1265a improves path_search_type:

path_search_type will now ignore absolute paths.

path_search_type should now be much faster with any search options.

[therube]

(I've not kept up on this thread, I've not read it, & I'm posting what I'm throwing in before I'll get to read it, so...)

Short story, !PUNC and PATH is broken for me (1265).

(more to come...)



1265

1265 is breaking stuff for me... all i did was put it in - no Pref changes...
(that's typically what i do for a new version)

1. double-click on Path, opens file rather then Path (<--- viewtopic.php?p=37853#p37853)
2. 169 274 does not find 169_274_401_32_2

Match Path is enabled (& know some changes related to that, don't know details...)
Ignore Punc is enabled (probably the same...?)

if either are disabled, then the search works

in any case, the changes are for the worse, for me
i can understand flipping a Pref, but the changes here are breaking behaviors that have existed - forever-ish
AND > OR, if that should matter


Search 'kate'
Results:
86 match path, ignore punc
146 ignore punc
154 [no filters]

154 to 146 (ignore punc)
146 does not find: WhiteStripes-kate_56k-256kbs_4.3MB.wmv - Why ? OK, search line filtering !blablabla
es_kate_sa.mpg - Why ? OK, search line !skate e_s^kate_s


so...

Match Path AND Punc
says only find 'kate' where 'kate' is at the beginning of a Path Part,
be it a directory or filename part
- why?
that's wrong, IMHO

PATH:tull AND !PUNC
ONLY finds /tull dot com/.*
ONLY because the directory part happens to start with /tull
(it would also find c:/test/tull_bridge.mp3, if that existed)
- 58 items are found
- 2,237 items are (correctly, again, IMHO) found with the same settings in 1253
PATH:tull AND !PUNC AND aqua
- finds NOTHING !


so, found: /test/kate is found.mp3
/kate 2nd bday/test.mp3
but, not found: /2nd kate bday/test kate is not found.mp3
(i'm not sure if that is right or not, i'm way past confused)

either there is a bug here
or the logic is wrong
&/or the logic is blowing my mind
as in i no longer know what to expect & i'm not getting results that i'd expect

& (i think it is) when Match Path is enabled
AND /some/ other filter, like Punc, or White-space, or Prefix...
heh, this about sums it up s/and/or/g rand() s/or/and/g
anyhow, which other filter is enabled, or which combination of filters are enabled
affect the results returned & with 1265 i've got no clue what to expect

i keep !PUNC enabled, almost always
i should probably keep !SPACE enabled too, but i ran into !PUNC first, so haven't explored !SPACE too much
i keep PATH enabled a lot, a lot enough that 1265, with !PUNC <> compute

if behavior is going to change to such an extent, old should be default, & force Pref on those who might
want this new...


-have to go back to my Jethro Tull example, above
-& see if it passes or fails?
(used a different JT test set)

anyhow, as i use both PATH & !PUNC, 1265 is rather broken - for me
(not to mention, if i happen to throw in other filters, say !SPACE
i'm apt to get different results yet again [aside from direct changes related to !SPACE itself]
that can only confuse me more then i am at the moment...)
[yep, you guessed it, i've got to revert to 1264]
(i'm writing this "blind", so i can't read about the actual changes to know if there is a switch...)
(likewise, i'm posting this before i'll get a chance to read about the actual changes, so if there
is a switch...)

when PATH: also enforces PREFIX:, as this essentially looks to do (when !PUNC is in effect)
you've severly limited results returned,
where if i wanted this, i would much rather be forced to use something like PREFIX:PATH:
understanding & knowing that i want to limit my results

[horst.epp]

2therube

1. double-click on Path, opens file rather then Path
Not confirmed here with 1265a x64, for me it works as described.
Double clicking in the path opens the path
and double clicking the filename opens the application for it.

Screenshot - 25.06.2021 , 19_15_37.png (33.84 KiB) Viewed 47976 times

[void]

Thanks for the feedback therube,

Everything 1.5.0.1266a fixes an issue with searching for paths.

I had recently added an optimization to improve path searching performance.
Unfortunately, this broke ignore punctuation path searching (Everything wasn't ignoring punctuation).
It also broke searching for text without a \ or / when using Match Path from the Search menu.

[aviasd]

Thank you for the feedback aviasd,

Everything 1.5.0.1265a improves path_search_type:

path_search_type will now ignore absolute paths.

Confirmed, tested on 1266 - Absolute path searches now working correctly (Also from TC)

path_search_type should now be much faster with any search options.

Confirmed, Ignore whitespace and ignore punc is enabled here and everything runs smoothly

Will check further and report back.

Just a small note - It would be nice if while matching a path using the /path_search_type option, a suffix symbol would be supported.

I.E:

Code: Select all

 win\sys\hosts$

Currently I have to seperate those, that is:

Code: Select all

win\sys\host hosts$

[void]

Thank you for the feedback aviasd,

win\sys\hosts$ should now work as expected with Everything 1.5.0.1267a.

Everything will now leave off the trailing ** when the endwith search modifier is enabled. (a trailing $ will set the endwith search modifier)

[aviasd]

Thank you for the feedback aviasd,

win\sys\hosts$ should now work as expected with Everything 1.5.0.1267a.

Everything will now leave off the trailing ** when the endwith search modifier is enabled. (a trailing $ will set the endwith search modifier)

Working great
Will test more and report.

[void]

Thanks for testing 1267a aviasd,

Please note that the performance of win\sys\hosts$ might not be the best.

There is currently no optimized path for endwith:**win**\**sys**\**hosts

[aviasd]

Thanks for testing 1267a aviasd,

Please note that the performance of win\sys\hosts$ might not be the best.

There is currently no optimized path for endwith:**win**\**sys**\**hosts

Thanks, I've noticed...

[void]

Everything 1.5.0.1287a will now convert \\ to **\ and add a trailing ** by default.

For example:
win\\hosts => win**\hosts**
tv\\futu => tv**\futu**
prog\\everything => prog**\everything**
control\\mouse
control\\keyboard
control\\network
control\\user
d:\\myfile.txt


paths can be absolute when using \\

While an empty folder name is valid in Everything, this shouldn't occur on any Windows file systems.
Use /path_search_type=4 to disable.



path_search_type

[void]

Everything 1.5.0.1290a will now convert \\ to **\** and improves performance.


For example:
win\\hosts => **win**\**hosts**