Option to sort direct matches first

[lifu]

I tend to keep Everything sorted by Date Modified, but there are times where I know the exact file/folder name of something and I want to get to it as fast as possible.

For example, if I type in Image, I would like it to put files and folders that have the filename of Image as the first results, even though the last modified dates they have are behind the other matches. (I'd prefer if it didn't take extension into consideration.)

While I know about wholefilename, this wouldn't exclude matches that aren't exact. Also, there isn't a wholefoldername modifier for some reason.

EDIT: Plus, I just noticed, wholefilename doesn't seem to be working in 1.5a yet.

[void]

Thank you for your feedback lifu,

For example, if I type in Image, I would like it to put files and folders that have the filename of Image as the first results, even though the last modified dates they have are behind the other matches. (I'd prefer if it didn't take extension into consideration.)

Everything 1.5 has the following search:
exact:stem:image

exact: = match the whole text. (same as wholefilename: or wfn:)
stem: = The basename without extension.

I am considering a relevance sort for a future release of Everything.

For Everything 1.4 or later, please try:

image.*
ww:image
regex:^image\.[^\.]*$

While I know about wholefilename, this wouldn't exclude matches that aren't exact. Also, there isn't a wholefoldername modifier for some reason.

wholefilename: matchs files and folders. (technically folders have a filename)
Please combine with the file: or folder: modifier to find files only or folders only.

EDIT: Plus, I just noticed, wholefilename doesn't seem to be working in 1.5a yet.

wholefilename: should be working in Everything 1.5a.
What happens? do you have any other search options enabled (eg: regex)?

[lifu]

wholefilename: matchs files and folders. (technically folders have a filename)
Please combine with the file: or folder: modifier to find files only or folders only.

EDIT: Plus, I just noticed, wholefilename doesn't seem to be working in 1.5a yet.

wholefilename: should be working in Everything 1.5a.
What happens? do you have any other search options enabled (eg: regex)?

Enabling Match Path seems to be breaking it.

[void]

wholefilename: with Search -> Match Path will match the whole path and filename.

Please use the nopath: search modifier to match only the basename.

For example:
nopath:wholefilename:image



To quickly match the whole basename, prefix the search with *\

For example:

*\image



Would a wholebasename: or wbn: search modifier be useful here?

Consider creating a wbn: macro:

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

Now, when you searching for wbn:Image it is replaced with nopath:wholefilename:Image

[lifu]

wholefilename: with Search -> Match Path will match the whole path and filename.

Please use the nopath: search modifier to match only the basename.

For example:
nopath:wholefilename:image

Huh, that seems a little unintuitive, considering even with Match Path on, I would still never consider the path part of a filename...

Would a wholebasename: or wbn: search modifier be useful here?

Consider creating a wbn: macro:

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

Now, when you searching for wbn:Image it is replaced with nopath:wholefilename:Image

That sounds good. Thanks for the tip.

[etl]

I hope this is still under consideration! It would make Everything so much more powerful than it already is.

I hope i don't sound like I'm trivializing the immense work that goes into developing this program when I say that it seems like there's a fairly simple way to implement this, at least in a rudimentary way: Include a search flag that makes the primary sort value be the filename's length minus the search term's length. In other words, if the filename is an exact match, the difference between those values is 0 and it should be the top result. If there are multiple exact matches, then they are sorted by whichever sort option is selected. For every additional character in a filename beyond the number of characters in the search term, the lower its ranking in the search results.

e.g. If you search for "image" sorted by name and with our hypothetical relevance flag enabled, then the results might look like this:

image
aimage
image1
0_image

So even alphabetically earlier results would appear after shorter-length results. That way it's not excluding inexact matches completely.

For example, if I type in Image, I would like it to put files and folders that have the filename of Image as the first results, even though the last modified dates they have are behind the other matches. (I'd prefer if it didn't take extension into consideration.)

Everything 1.5 has the following search:
exact:stem:image
exact: = match the whole text. (same as wholefilename: or wfn:)
stem: = The basename without extension.

The issue of nopath: and stem: could be addressed in a pretty intuitive way with a couple lines of boolean logic, along the lines of:

Code: Select all

IF {searchterm} does NOT contain {backslash_char} 
    THEN include nopath: modifier
END IF
IF ({searchterm} does NOT contain {period_char}) OR ({substring from {period_char} to end} contains {backslash_char})
    THEN include stem: modifier
END IF

The rational is that if the user is searching all or even part of the full filepath, it will have to include backslashes (or forward slashes, if the setting to replace one with the other is enabled). Similarly, if the searchterm is to include the extension, it must contain a period. (The extra bit about the substring is to exclude false positives due to periods in folder names earlier in the filepath.)

@void what do you think?

[void]

A rank sort is still on my TODO list.

This can be done now with column formulas.

Please consider the following Everything 1.5 search:

file: <path:exact:image a:=1>|<nopath:exact:image a:=2>|<exact:stem:image a:=3>|<ww:stem:image a:=4>|<image a:=5> sort:column-a

file paths matching exactly "image" are shown first.
file names matching exactly "image" are shown second.
file stems matching exactly "image" are shown third.
file stems matching the whole word of "image" are shown fourth.
file names containing "image" are shown last.



If you find this useful, please consider creating a filter:
In Everything, from the Search menu, click Add to filters....
Change the Name to:
Exact Rank
Change the Search to:
file: <path:exact:$param: a:=1>|<nopath:exact:$param: a:=2>|<exact:stem:$param: a:=3>|<ww:stem:$param: a:=4>|<$param: a:=5> sort:column-a
Change the Macro to:
exactrank
Click OK.

Now you can search for exactrank:image
which will be replaced with:
file: <path:exact:image a:=1>|<nopath:exact:image a:=2>|<exact:stem:image a:=3>|<ww:stem:image a:=4>|<image a:=5> sort:column-a

You can view the rank by showing Column A.



Match Path is normally disabled.
Using a path separator in your search term will enable match path.
Users will want terms without a path separator to match anywhere in the path with Search -> Match Path enabled.

Using name: is also another alternative to nopath:

Thank you for the suggestions.

[etl]

Beautiful, thank you for the swift reply! I had no idea about column formulas (I usually stay away from alpha builds, but in this case I may have to make an exception!)

I'm still trying to understand the syntax based on your examples, but it'll become more clear when I install it and mess around with the terms myself. I believe this should also address the priority sorting feature from this thread:

How to make everything results prioritize user files on top results

To limit your results to your user folder c:\users\<your username>, search for:
"c:\users\<your username>\"
where <your username> is your username.

Searching for
\<your username>
would also return similar results and might be easier to type (provided there's no spaces in your username -you'll need to escape spaces with double quotes).

If you find you are using this search often, please consider adding a filter:

• From the Search menu, click Add to filters....
• Change Name to: User files
• Change Search to: "c:\users\<your username>\"
• where <your username> is your username.
• Click OK.

While not quite what you want, Everything does have a run count property for files. When sorting by run count, files with the highest run count are shown first.
You can set the run count for a file by either, running it, or right clicking the file and clicking on Set run count..

Using column sorting, I think the goal of "give precedence to matches in user folders" could be accomplished by adding one more formula up front, something along the lines of:

file: <exact:%USERPROFILE%\*\$param: a:=1> | <path:exact:$param: a:=2>|<nopath:exact:$param: a:=3>|<exact:stem:$param: a:=4>|<ww:stem:$param: a:=5>|<$param: a:=6> sort:column-a

Many birds, one stone! Very nice work with this feature.

[etl]

This can be done now with column formulas.

Please consider the following Everything 1.5 search:

file: <path:exact:image a:=1>|<nopath:exact:image a:=2>|<exact:stem:image a:=3>|<ww:stem:image a:=4>|<image a:=5> sort:column-a

I'm not sure if I'm doing this wrong or if there's a bug, but column formula sorting doesn't seem to work correctly for me. Try this simplified version of the macro you described:

Code: Select all

<exact:stem:$param: column1:=1> | <$param: column1:=2> sort:column-1 addcolumn:column-1

This macro should put all the direct matches first, followed by everything else, right? And in the "Column 1" column, it should be a lot of 1s followed by a lot of 2s, right? Yet when I use that macro, the column sorting doesn't appear to work properly. While search results are correctly *assigned* a value of 1 or 2 in Column-1, the column itself is not sorted; there will be a dozen or so results with a "1" value, followed by a dozen or so "2" results, followed by two dozen more "1" results. Clicking the column header has no effect on the sorting.

I've double-checked all my Everything default options to make sure there's nothing that might affect sorting. Can you try out the code I pasted above and see if it works properly for you?

--
Everything v1.5.0.1360a.x64
Windows 11 Enterprise

[void]

Are the top results all folders? then the bottom results all files?
Everything doesn't mix files and folders when sorting by column-a
An option to do this is on my TODO list.

Consider including the following in your filter:

file:

[etl]

Are the top results all folders? then the bottom results all files?
Everything doesn't mix files and folders when sorting by column-a
An option to do this is on my TODO list.

You're absolutely right. It looks like it shows the "1" folders, then the "2" folders, then the "1" files, and then the "2" files. When you say, "mix files and folders," I assume you mean that it would show 1-1-2-2 instead of 1-2-1-2. This would be a fantastic addition, as sorting direct matches first is of limited value if it shows direct matches for folders first, but direct matches for files are stuck all the way below the list of all non-direct matched folders.

[void]

There's already a Mix files and folders option under View -> Sort By -> Mix files and folders.

However, it doesn't work with custom columns yet.
Mix files and folders will currently only work for Name, Path, Size and Date Modified properties.

Support for mix files and folders with custom columns is on my TODO list.

[vertigo]

I'm often finding myself wishing Everything had intelligent sorting (by default, without requiring using additional search commands). What I typically feel would be very helpful is simply listing results that start with the search term first, basically like enabling regex mode and adding a ^ to the beginning of the search, but without having to do that and still showing other results, but simply prioritizing those. I think that would help bring the intended result(s) toward the top most of the time.

[void]

A ranked sort is on my TODO list.

Thank you for the suggestions.