[Added] [Suggestion] /match_start_of_filename_with_caret=1 with match path enabled - match last path component

[aviasd]

Hi,
When enabling /match_start_of_filename_with_caret=1 and match path is enabled:
typing ^ would need to match from root of drive -

Code: Select all

^c:\folder\file1

IMO, this doesn't have any real world use while prefix: is working as expected with match path enabled (and is much more useful )

Code: Select all

prefix:file1

Aren't they supposed to work the same?
Suggestion is to make caret prefix consistent with prefix:, so that ^file1 would return the match for c:\folder\file1, even with match path enabled

Thanks
Correction:with match path enabled, prefix: would match any path component prefix, I dunno if caret prefix should be the same or just the last part...(For me it makes sense to match the last component)

[NotNull]

You can use

\file*

instead when match path is enabled (see also wildcard matching).
(or nopath:^file , but that is a lot of typing).


In my opinion ^ should still match the start of the filename. When match path is enabled, the filename expands from "filename.txt" to "c:\path to\filename.txt". If it would do something else, that would get confusing [1].

In Everything 1.5 'filenames' also includes thos in virtual folders, like "Control Panel\All Control Panel Items".
Like searching for ^con \adm - with Match Path enabled - will find "Control Panel\All Control Panel Items\Administrative Tools".


[1] I am all for "Do as I say" instead of "Do as I want", because systems very seldom seem to understand what I want. So I prefer to "say" something different to get what I want

[void]

^ should match the start of the full path (when match Path is enabled)

Could you please give an example as to how you are using Match Path?
Maybe I can improve path matching for you with this setting off.

I will look into allowing ^ in search functions that take a filename (when match_start_of_filename_with_caret is enabled).
For example:
basename:^file1

Aren't they supposed to work the same?

prefix:text matches words in the filename (full path and filename when match path is enabled) starting with text.

^ matches the start of the filename (full path and filename when match path is enabled) only.

[aviasd]

In Everything 1.5 'filenames' also includes thos in virtual folders, like "Control Panel\All Control Panel Items".
Like searching for ^con \adm - with Match Path enabled - will find "Control Panel\All Control Panel Items\Administrative Tools".

Haven't taken into account Virtual folders. That's a valid point.
I thought that if one wants to look in let's say C: for a file, he can just type C:, since all the root drives are unique already. No need to prefix with a caret.

[1] I am all for "Do as I say" instead of "Do as I want", because systems very seldom seem to understand what I want. So I prefer to "say" something different to get what I want

I agree with that statement.
..but - ^ and $ looked like a niche feature for people that tend to use regex on a regular basis so I thought improvement based on usability as opposed to consistency is applicable here.
Besides, the help says filename would be matched, so I assumed it applied to the filename in match path as well. ( I guess we could argue here what is filename until v1.6 )

Could you please give an example as to how you are using Match Path?
Maybe I can improve path matching for you with this setting off.

I elaborated on my general workflow Here
In general, it allows me to narrow my results using partial folder names containing what I'm looking for.

But as an example of how to use caret in search ( Match path enabled):
to find C:\Windows\System32\Drivers\ETC\hosts
I would type: prefix:hosts
Then system
And that's it. I already see what I want.

with match path Enabled I need to use prefix: instead of ^hosts.

I tried to override caret with a macro /define ^<search> prefix:search:
But that necessitates me to type ^: to apply. Don't like it so much. ( Not so regexy )

[NotNull]

( I guess we could argue here what is filename until v1.6 )

.. and beyond ..
(btw: c:'\path to\filename.txt" is officially called a fully qualified filename. Not to start a discussion, though .. )

But you made some valid points here for practical day-to-day usage.

Regex matches the start of a filename the basename of a file with the caret (^)

and all is consistent (thank you, that was the word I was looking for) again
But no doubt implementing that will have some technical challenges.

(I have Match Path disabled 99% of the time, btw)

[aviasd]

Regex matches the start of a filename the basename of a file with the caret (^)

and all is consistent (thank you, that was the word I was looking for) again

Basename's definition is to the trailing name component of the file in question regardless of its path - also without the extension i.e: the basename of c:\path1\file1.txt is file1.

Name is actually more correct. (or filename i guess, MS uses name for just name and fullname for fully qualified path )

In the strict regex world:
^ (caret) matches the beginning of Line with zero count ( meaning that the first letter in the line is still not matched)

So the question is: what is a line?

In the everything world, the meaning of line varies according to match path enabled or disabled:
with match path:
Line = path+"\"+filename

w/o match path:
Line = filename

My suggestion is actually an anomaly from the regex world since with match path, the "line" is actually starting with the path part, while my suggestion was to ignore that "start of line" and still treat "line" as it is matched without the match path feature...

So in terms of consistency ( ) with regex definitions, keeping it as it is is more correct, in terms of usability it's something else.

Hope I succeeded in explaining...

[NotNull]

Hope I succeeded in explaining...

Thanks for taking the time to explain.

That is why I mentioned the technical challenges.
In the current implementation, it will be something like this (I guess):
When ^or $ is detected with regex disabled and these ^/$ settings enabled, escape special characters - \ ^ ( ) { } [ ] + . $ - with a \, put the ^and $ in place and do a regex search.

In this new idea, that will get a lot harder: ^file would translate to regex ^.*\\file[^\\]*$ or ^.*\\file(?!.+\\)
That is doable, but when searching for ^file$, that ^'formula' is no longer valid and something like ^.*\\file$ is needed.
Now two routines are needed. Still doable, but might deviate too much from the initial design.Will be slower too.

Alternatively, a nopath: modifier could be prefixed to the initial query ( like nopath:regex:^file ). That will basically undo the Match Path setting.


FWIW: startwith: has the same behaviour as ^ : when Match path is enabled, it will start matching with C:\..
It is simply not a good combination to use.

[void]

Everything Definitions:

Code: Select all

File:      | C:\Program Files\Everything\Everything64.exe
-----------|---------------------------------------------
Basename:  | Everything64.exe
Extension: | exe
Path:      | C:\Program Files\Everything
Full Path: | C:\Program Files\Everything\Everything64.exe
Stem:      | Everything64

In Everything, "Filename" can mean the "Full Path" or just the "Basename".


For the next alpha update,
/match_start_of_filename_with_caret=2
will match only the basename.


https://stackoverflow.com/questions/2235173/what-is-the-naming-standard-for-path-components

[aviasd]

For the next alpha update,
/match_start_of_filename_with_caret=2
will match only the basename.

Cool Tested on Everything 1.5.0.1258a. Works exactly as I asked

https://stackoverflow.com/questions/2235173/what-is-the-naming-standard-for-path-components

Should have known better than verifying my answer using MS:

On PowerShell ( also PowerShell core )

Code: Select all

$File = get-item test.txt
$file.basename                                                                                         

Output:
test

On linux (zsh)

Code: Select all

basename test.txt


Output:
test.txt

MS is usually out of standard, dunno why I thought this would be different. ( it's also mentioned on the stackoverflow link in the second reply - section 5.)

[void]

Good to hear the match_start_of_filename_with_caret=2 option in Everything 1.5.0.1258a is working as intended.

match_start_of_filename_with_caret