folders: parameter uses

[anmac1789]

What parameters can I use with folders: ? I know if i type folders:DCIM it searches for anything with "DCIM" as string but what else can I use with this?

[void]

folders: is a search modifier.

You can combine search modifiers, for example:

folders:regex:^DCIM$

folders:case:startwith:DCI



You can also combine search modifiers with search functions, for example:

folders:date-modified:today



The folders: search modifier doesn't need to be used with other search modifiers/functions.
You can use folders: on its own to match all folders, for example:

folders: date-modified:today

which means:
<all-folders> AND <date-modified:today>

which gives the same results as:
folders:date-modified:today

[anmac1789]

can I use something like folders:<dc==dm;dc:==da;dm:==da:> ??

[void]

Search modifiers can be applied to < > groups.



Please try:

folders:<dc:==dm: dc:==da: dm:==da:>



This is treated the same as:

folders:dc:==dm: folders:dc:==da: folders:dm:==da:



which would show the same results as:

folders: <dc:==dm: dc:==da: dm:==da:>

(note the space after folders:)

[raccoon]

I asked this before but I didn't really understand last time.

Is there any functional difference to attaching parameters/groups/modifiers to the folders: verb, versus having them separated?

I still see folders: (and files:) as a filter, and not a function. I'd argue that it be described as a filter.

[void]

Is there any functional difference to attaching parameters/groups/modifiers to the folders: verb, versus having them separated?

The results will be the same.

Internally it is different:

folders:abc == search for folders containing abc
folders: abc == search for all folders AND files/folders containing abc

While it might look like folders:abc would give the best performance, both will give the exact same performance.

Both searches actually get compiled into the same search byte code.
(check the verbose debug output which shows the search op trees)

folders:abc =>

Code: Select all

FOLDER TERM START 0000000bd2971edc
0000000bd2971edc 20e01120 M 0000000000000000 N 0000000000000000 OP 5 abc
FILE TERM START 0000000bd2971edc
0000000bd2971edc 20e01120 M 0000000000000000 N 0000000000000000 OP 3 abc
remove NOTHING term
FOLDER TERM START 0000000bd2971edc M 000000000012e270 N 000000000012e3a0
0000000bd2971edc 20e01120 M 000000000012e270 N 000000000012e3a0 OP 5 abc
FILE TERM START 000000000012e3a0 M 000000000012e270 N 000000000012e3a0
FOLDER OPs:
 /- MATCH
5 abc
 \- NOMATCH
FILE OPs:
NOMATCH

(no file search ops are emitted)

folders: abc =>

Code: Select all

FOLDER TERM START 0000000b88a01edf
0000000b88a01edf 20e01120 M 0000000b88ab1edc N 0000000000000000 OP 2
0000000b88ab1edc 20e01100 M 0000000000000000 N 0000000000000000 OP 5 abc
FILE TERM START 0000000b88a01edf
0000000b88a01edf 20e01120 M 0000000b88ab1edc N 0000000000000000 OP 3
0000000b88ab1edc 20e01100 M 0000000000000000 N 0000000000000000 OP 5 abc
remove EVERYTHING term
remove NOTHING term
FOLDER TERM START 0000000b88ab1edc M 000000000012d730 N 000000000012d860
0000000b88ab1edc 20e01100 M 000000000012d730 N 000000000012d860 OP 5 abc
FILE TERM START 000000000012d860 M 000000000012d730 N 000000000012d860
0000000b88ab1edc 20e01100 M 000000000012d730 N 000000000012d860 OP 5 abc
FOLDER OPs:
 /- MATCH
5 abc
 \- NOMATCH
FILE OPs:
NOMATCH

(the match nothing file search ops are removed during optimization)

I still see folders: (and files:) as a filter, and not a function. I'd argue that it be described as a filter.

folders:/files: are really search modifiers.
Not search functions.

Each search term can have zero or more search modifiers.
A search term can be a simple "ABC" search or a search function.

If you look at the Folder filter, it actually sets the search to: folder:

Calling search modifiers "filters" might be too confusing with Search -> filters (eg: Audio / Video)

[void]

Maybe a better way to look at this:

folders: abc

is treated the same as:

folders:* abc

The empty search term after folders: matches all files/folders.

[raccoon]

I suppose there's a difference between a modifier and a filter, insofar as a filter can be augmented by the user, but I'm still not yet prepared to call folders: a modifier since modifiers generally augment the context of the verb semantically... as in case:, or wholeword:, or diacritics: or regex:, while filters augment the context of the results themselves. I cannot reproduce these modifiers as filters (ok, i'm sure there's a convoluted way ), yet, I can add these filters:

audio = ext:wav;mp3;oog
folder = attrib:D

[void]

attrib:D

It's probably important to note:

There are two databases in Everything, one for folders and one for files.

a search like:

case:ABC

creates two searches, one for the folders db and one for files db.



In this sense, the folders: search modifier will only create a search for the folders db and nothing for the files db.



attrib:d will search the folders db and the files db, although no files will have the d attribute.
(technically, Everything is smart enough to know this and will optimize attrib:d into searching folders only)

[void]

In short:

folders: doesn't take any parameters and limits the search to the folders database only.

[ChrisGreaves]

There are two databases in Everything, one for folders and one for files.

important indeed1 i think that this will help to understand much of what my old brain tries to process.

I have been thinking of everything as searching a list of fullnames - drive,path,name,extent.
Now I can think of Everything as sometimes looking up one database; sometimes the other; and probably, sometimes both.

I know that Everything works, but sometimes a high-level view of machinery helps to know how to make use of a machine or tool.
(Carpenty chisels 101: You say that wood has a grain?)
Thank You