Autocomplete in search

[cata_solo]

It will be a great addition to get autocomplete filters in the Search input line. For example, if I type siz to see with light grey color size:

This will help to easy learn the filters, macros and avoid mistakes.

PS - I am sorry if this was suggested before.

[void]

Search function suggestions are on my TODO list.

Thank you for the suggestion.

For now, please try the Advanced Search under the Search menu.

[AntonyD]

Hi!

It's been a while, and I'd like to talk about this feature again.
As far as I understand, the proposed functionality is still not ready.
And I think "that" - what you answered in another thread:

I will add a Search builder dialog at some stage.

I am working on Ctrl + space to autocomplete all search functions too.

Is still only in plans?

Of course, any improvement that you have already made or are doing is only beneficial to this excellent tool.
But still, the complexity of working with a huge set of search capabilities makes it very difficult to use it closely.
In reality, without the presence of some kind of wizard for creating a search bar, you have to review mountains
of topics on this forum, reread the short help and experiment, experiment, experiment, experiment....
And this generally only complicates and slows down the overall pace of product usage.

Is it possible to expect that such a wizard will be in the near future?

For example, I needed to find a text file containing certain text. And when I wrote the search string,
it felt very intuitive to write 'contains:'. However, after rereading the help, I had to write 'content:'
If this wizard had been ready, I would not have made such a mistake and wasted time.

[void]

I will add a Search builder dialog at some stage.

This is planned for Everything 1.6.
I will take too long to add to Everything 1.5.

I am working on Ctrl + space to autocomplete all search functions too.

Complete Word is done.
Tools -> Options -> Keyboard -> Search Edit | Complete Word -> Assign: Ctrl + Space
The default is Ctrl + Space, but if you used an older version, Ctrl + Space will stay assigned to: Search Edit | Auto Complete Search

I have on my TODO list to add a suggest parameter option: Ctrl + Shift + Space
So you would type in filter:
and a context menu/list of filters will show automatically.
Ctrl + Shift + Space would forcefully show this list.
-Same as visual studio.
I'm not sure this will happen for Everything 1.5... Maybe during beta.
Same with size:, which would show size: usage and give some examples.
Other functions would behave the same.

Of course, any improvement that you have already made or are doing is only beneficial to this excellent tool.
But still, the complexity of working with a huge set of search capabilities makes it very difficult to use it closely.
In reality, without the presence of some kind of wizard for creating a search bar, you have to review mountains
of topics on this forum, reread the short help and experiment, experiment, experiment, experiment....
And this generally only complicates and slows down the overall pace of product usage.

Everything will stick to searching filenames only.
Anything other than that you'll need a guide.
It will be impossible to support all the properties in Everything without bloating up the UI more..

Is it possible to expect that such a wizard will be in the near future?

No.

For example, I needed to find a text file containing certain text. And when I wrote the search string,
it felt very intuitive to write 'contains:'. However, after rereading the help, I had to write 'content:'
If this wizard had been ready, I would not have made such a mistake and wasted time.

I will add a contains: alias for content:

A good place to start:
Search menu -> Advanced Search -> A word or phrase in the file
-or-
Right click the Search box -> Search Function -> Content Search

[AntonyD]

Thank you so much for such a good answer. I tried to follow all the advice, but I already "broke" on the very first point.
Ctrl+Space, if I understand correctly, is now assigned to two commands:
Search Edit | Auto Complete Search
Result List | Toggle Focus Selection

And Ctrl+Shift+Space assigned to:
Result List | Toggle Focus Selection Extend

Moreover, I don't even understand what these "Toggle s" are supposed to do. Especially for "Extend" ver.
Even translating their names into my language, I still don’t quite understand what action to expect from them.
But the most important thing is - will such an intersection of already existing commands, assigned to this same hotkey, not break their support?
I mean - ONE hotkey - but TWO different commands? Complete Word & Toggle Focus Selection.

P.S.
It seems that after applying your advice, I actually got an expected dropdown list where I could find "content:". But then I have a suggestion - not just to move the input focus through this list to the most suitable entry (based on the matching letters entered and the letters in the entry name itself) when typing letters on the keyboard, but also to actually filter this list. So when I enter "cont", there should be ONLY those entries in this dropdown list whose names start with or contain those letters. That is, the list should definitely be reduced in size - so that I can easily browse through the entire list of matches with the mouse. Otherwise, right now I will just get the input focus moving to the entry "content:", but the list will contain absolutely all entries, and with the mouse I will be calmly moving from the entry starting with the letter A to the entry starting with the letter Z.

But in any case - I express my immense appreciation and gratitude for what you have achieved so far. This is very helpful in using your wonderful product! I wish you all the strength and prosperity and a successful personal life. After all, it's not only necessary to create such a wonderful product))) but also to live!

[AntonyD]

By the way, how does the application of these filters/functions/search modifiers work? Instantly after they are entered in the search box? But then something is wrong with the 'by content' function. I was searching for the file "ls.exe" - since initially I was not looking for an exact match, many files were found - including those where there was simply a match of these characters in the name. And that is correct. There were 74 files. But as soon as I entered in the search field "content:", the result suddenly narrowed down to 34! BUT I didn't add anything to the body of the function! I mean, I literally have nothing after the colon! So by what logic did this emptiness suddenly become a filter, allowing to narrow down the original 74 files to just 34?

I could also assume - if these 34 files were literally empty. Then the emptiness after the colon in the function "content" really turns into the emptiness of the file contents and only those records that are files with zero size are filtered out. BUT no! All the files have substantial sizes!

[AntonyD]

P.P.S.
I compared two versions of the INI file from the tool - one version belongs to a clean installation, and the other is an update over the old 1.4.
And in the version of the INI file from the update, I found the following differences (besides those that are understandable and acceptable - for example, the window X/Y-coordinates, which are different in different versions because the window has actually shifted. Or cases when you have clearly just renamed variables more accurately: IT WAS path_and_name_column_visible. IT BECAME full_path_column_visible.):

Code: Select all

wildcards=1
pinyin=0
tray_icon_filename=
register_raw_input_devices=1
property_system_priority=0
property_builtin_handler_priority=0
metadata_efu=1
metadata_efu_max_search_depth=255
window_corner_preference=0
ime_end_composition_search_delay=50
search_command_allow_all=0
sh_change_notify=1
index_journal_source_date_changed_visible=0
index_journal_source_date_changed_wide=0
index_journal_source_date_changed_order=2
file_duplicate_tab_keys=
result_list_select_focus_extend_keys=9248
result_list_toggle_focus_selection_extend_keys=9504

These variables are no longer present in the new version of the INI file that was generated after a clean installation. The question is - were these variables correctly 'absorbed' by the installation of 1.5 over 1.4? After all, for some reason they still remained in the INI file. IF they are, let's say, no longer valid from the perspective of their use in the utility of version 1.5 - then they should probably have all been deleted from the INI file? Isn't it?

P.P.P.S.
Ufff....
What a wonder. I wrote the entire text above and only now realized that one moment would also NOT be possible in the correct case of an "above" update:

IT WAS path_and_name_column_visible. IT BECAME full_path_column_visible.

It is illogical that after the utility update, the variables that were previously written in one way and are now used with a different names in the utility's code - remain in the INI file* in the old naming. BUG?

* - I mean that these naming's are left intact in version of INI which is using by Everything instance v1.5 installed on top of old v1.4 of this tool.

[tuska]

I mean, I literally have nothing after the colon!

What is the exact search query?

[AntonyD]

ls.exe content:

[tuska]

ls.exe content:

... gives me the following result in ‘Everything’ 1.5.0.1399a (x64)
0 items (0 files, 0 folders)

ls.exe
61 items (61 files, 0 folders)

content:ls.exe
43 items (43 files, 0 folders)

[AntonyD]

Well, you made it more logical and correct, IMHO.
You have exactly 0 files with an empty body modifier of function "content:".
Unlike me, where there is some positive number.

[tuska]

Well, you made it more logical and correct, IMHO.
You have exactly 0 files with an empty body modifier of function "content:".
Unlike me, where there is some positive number.

Please try forcing a rebuild:

• In Everything, from the Tools menu, click Options.
• Click the Indexes tab on the left.
• Click Force Rebuild.
• Click OK.

[AntonyD]

I certainly did that - but my result did not change. The behavior is exactly the same as I described above. Let's wait for the developer's responses - what he will say about the behavior. After all, he created the logic for these functions. Maybe something really remained from the old INI-keys that I mentioned a little earlier - and they negatively affect current performance. By the way, as a supplement, I note that all found files with an empty body 'content:' are either MUI, XML, or AUX files.
And if I can still somewhat accept XML files - they are text-based and searching is easily possible there, then when it comes to AUX and MUI, one cannot say the same - these are binary files. And what could the search function even be searching for in principle in such files?

[tuska]

I note that all found files with an empty body 'content:' are either MUI, XML, or AUX files.

I would check whether you have given a filter in ‘Everything’ accidentally the macro name: content.

[AntonyD]

I did not add anything from my own.
Only predefined: audio, zip, doc, exe, dir, image and video Filters do exist in my instance of Everything.

[void]

Ctrl+Space, if I understand correctly, is now assigned to two commands:
Search Edit | Auto Complete Search
Result List | Toggle Focus Selection

Yes, Ctrl + Space is bound to both.
Take note of the "Use in" value.

"Search Edit | Auto Complete Search" will only work when Ctrl+Space is "used in" the search edit.
"Result List | Toggle Focus Selection" will only work when Ctrl+Space is "used in" the result list.

Moreover, I don't even understand what these "Toggle s" are supposed to do.

Toggle the selection.

Same as Windows Explorer:

• Select an item.
• Press Ctrl + Space
• The item is unselected.
• Press Ctrl + Space again.
• The item is selected.

Especially for "Extend" ver.

The terminology came from Visual Studio.
Extend == Extend the selection from the current selection mark. Basically, SHIFT key actions to select a range.
Focus == Don't clear the selection and move the focus. Basically, CTRL key actions to move the focus.

But the most important thing is - will such an intersection of already existing commands, assigned to this same hotkey, not break their support?

Only if there's conflicting keyboard shortcuts with the same "Use In".

I have a suggestion - not just to move the input focus through this list to the most suitable entry (based on the matching letters entered and the letters in the entry name itself) when typing letters on the keyboard, but also to actually filter this list.

Same as visual studio complete word.
Shows the whole list.
Typing in cont will jump to the entry starting with cont.

By the way, how does the application of these filters/functions/search modifiers work? Instantly after they are entered in the search box?

Instantly.

But then something is wrong with the 'by content' function. I was searching for the file "ls.exe" - since initially I was not looking for an exact match, many files were found - including those where there was simply a match of these characters in the name. And that is correct. There were 74 files. But as soon as I entered in the search field "content:", the result suddenly narrowed down to 34! BUT I didn't add anything to the body of the function! I mean, I literally have nothing after the colon! So by what logic did this emptiness suddenly become a filter, allowing to narrow down the original 74 files to just 34?

content: (with no argument) will only match files with non-zero length content.

All search functions behave like this.
For example, genre: will only match files that have a genre value.
-or-
artist: will only match files that have an artist value.

Specify an argument with your function or use the whole: search modifier:
whole:content:

Even if the file has size, there's no 'content' property value.

binarycontent: would work as you expect. Provided the file size is > 0

Or cases when you have clearly just renamed variables more accurately: IT WAS path_and_name_column_visible. IT BECAME full_path_column_visible.):

I will probably drop support for 'full_path' moving forward.
This wasn't used in Everything 1.4 and was only used in earlier 1.5 alpha builds.
path_and_name might also change as I work on finalizing localization..
For Everything 1.4 settings, these should all correctly map to Everything 1.5 settings.

[AntonyD]

Thank you once again for such a thorough investigation on your part)))
So now I kindly again ask you to pay attention once more to the following thoughts of mine:

1) You write that the support for the dropdown suggestion list was modeled after the Visual Studio development environment. Well, that is quite a reasonable approach. But that only suggests that it seems you have not worked with the VisualAssist component which enhances the interaction with Visual Studio. Greatly! Even back in the heyday of version VS№6 VisualAssist was VERY helpful in work. And even back then it already implemented a filtered suggestion list, and I had practically forgotten what the original list from Visual Studio looked like.
Those were good days, it's a shame they are over(((
SO - Filtering always helps to focus on WHAT you are looking for. And if with the mouse I can scroll through this reduced list of suggested input options with a single touch, it further improves interaction. Currently there is nothing like this. Yes, certainly the list is already functionally useful and works well We can use, I will use it! But I am simply modestly suggesting to implement this additional option of simultaneous filtering in the future if possible.


2.a) Let's get back to keyboard shortcuts. There is one point you missed. As well as an entire list of entries in the INI file that had no corresponding pair... When you initially recommended using the Ctrl + Shift + Space combination you mentioned that you PLAN to use it only in the future. This means that UP UNTIL that moment this combination should NOT have been used anywhere in the utility's default settings. And I showed you – which surprised me the most – that this combination ALREADY EXISTS in the list of uses! And moreover it is assigned to unclear for me an action!
--------------------
By the way, I will also describe a bug that appeared in the dialog for assigning a new hotkey to the selected command. The tooltip that appears when hovering over the 'Use in' list DOES NOT disappear when I move the mouse cursor away from this list down to the 'OK/Cancel' buttons. As a result, it completely covers the visibility of these buttons, at least for my translation language. And there is a lot of text there.
--------------------
Let's continue I wrote "unclear an action" coz this existing combination visually does nothing! That is I physically do not see any difference in the actions with the resulting search list when pressing this hotkey, after pressing it, when interacting with the cursor control keys. No combination of these actions changes in any way the standard single selection of the current row with focus in the resulting list. For a counterexample, if we take the hotkey Ctrl + Space for the command "Result List | Toggle Focus Selection" => then here everything works exactly as described by you in the answer above. The Focus is either set or removed from the single current row in the resulting search list. But "Toggle Focus Selection Extend" (as I see it now) does not work at all. And this is precisely where my question came from + my list of mismatched entries in the INI file, which you skipped in your analysis. The fact is that on a CLEAN installation of the utility there is simply NO command "Result List | Toggle Focus Selection Extend" in the INI file, no hotkey assigned to it, no list record in Settings dialog for Keyboard tuning!
2.b) That's why I showed the list of mismatched entries in the INI file — so that you could assess the correctness of updating the old version 1.4 to the new version 1.5 in this regard. What if something went wrong? Since there are still some old keys left in the INI file after the update, which are NOT present in the clean INI file. In this context it is possible that the functionality of commands tied to these keys simply does not work in the current version of the utility. Again — IF we use the hotkey from the old version of the utility "Toggle Focus Selection Extend" —> I don't see its action in the resulting list!
And in the hotkey settings dialog in the new clean installed version of the utility there simply is no command "Result List | Select Focus Extend"!
And in the updated version of the utility, where it yet does exist (that's actually where I got this data from), using this hotkey also doesn't visually change anything just like "Toggle Focus Selection Extend".


3) And now let's move on to probably the most difficult question. To the concept of the word "content". A little earlier you agreed that the alias "contains:" can also be added to this word. This is fine, but right now it in no way aligns in my mind with your given answer:

content: (with no argument) will only match files with non-zero length content.

All search functions behave like this.
For example, genre: will only match files that have a genre value.
-or-
artist: will only match files that have an artist value.

Specify an argument with your function or use the whole: search modifier:
whole:content:

Even if the file has size, there's no 'content' property value.

binarycontent: would work as you expect. Provided the file size is > 0

+

Instantly.

SO, If immediately after typing (or selecting from the list) the correct search modifier (function, macro) you apply it, that means that any of these entities has some default value — and with it, I can allow myself to use this chosen entity INSTANTLY. So the question is — what exactly is this empty def.value for "content:"? IF it’s something from the realm of multimedia file tags (as in your example with the entities "genre:" and "artist:"), then I can start to grasp the logic and understanding a little — even an empty value for the entity simply means checking for the EXISTENCE of that tag in the multimedia file itself. Because we know that some files were created WITHOUT descriptions for these tags. And we want to find the files where the tag WAS actually used.
But I (when I wanted to use this entity "content:") was talking about an pure INTERNAL textual search (and that's exactly why I intuitively wanted to use the "contains:" entity) within the file as a whole! That's why your answer left me confused — so WHAT exactly are you trying to find in the file when you use this entity? And if things are really like that right now — and this word only relates to multimedia formats — then, of course, а word "contains:" cannot in any way serve as an alias for this initial command "content:"! "contains:" can and should only handle a full-text search throughout the entire file data!

Once again - about my experience. Initially with the query "ls.exe" the utility found 74 files. But with the query "ls.exe content:" the resulting list was reduced to 34 (And again a miracle – just yesterday checking this query gave 34 total found files. And today it's only 23!!!). However the files found are either MUI, XML, or AUX files.
And if I can still somewhat accept XML files - they are text-based and searching is easily possible there, then when it comes to AUX and MUI one cannot say the same - these are binary files. And what exactly were you able to LITERALLY find in these files? The presence of the "content" tag/property? Impossible. This word/tag/property does not exist in these files, neither in text nor in binary form.
And by the way! About the mentioned "binarycontent:" - I tried it and was surprised again. Initially there were 74 files. And after applying this search entity, I got... 73 files! ONE file disappeared from the list. You write that the entity operates by file size ("Provided the file size is > 0"). But the missing file DOES have a size! That is the search results for the query "ls.exe" and "ls.exe binarycontent:" according to the explanation should not have differed! But practice shows that this is not the case...

[AntonyD]

Is it possible that this forum engine doesn't support spoiler formatting in the text? Hidden text by default?
That can't be. Is the tag blocked or something?

[tuska]

Is it possible that this forum engine doesn't support spoiler formatting in the text? Hidden text by default?
That can't be. Is the tag blocked or something?

[Suggestion] - phpBB® Forum Software - Add "Spoiler BBCode"

[void]

it already implemented a filtered suggestion list

I will consider an option to filter the suggestion list.

The tooltip that appears when hovering over the 'Use in' list DOES NOT disappear

Unable to reproduce the issue my end.
The tooltip disappears when moving away from the list.
What translating language are you using?

But "Toggle Focus Selection Extend" (as I see it now) does not work at all.

Select any item in the main Everything result list.

Press Ctrl + Down a couple times to focus another item.

Press Ctrl + Shift + Space
The range from the first selected item to the current focus is selected.

While Ctrl is not held down, and changing the item focus, Everything will internally mark the new focus as the start of a range.
Using Shift will extend the range from internally marked item to the new focus.
This is the same behavior as Windows Explorer.

The fact is that on a CLEAN installation of the utility there is simply NO command "Result List | Toggle Focus Selection Extend" in the INI file, no hotkey assigned to it, no list record in Settings dialog for Keyboard tuning!

A clean installation has no ini file.
No ini file == default keyboard settings.

The default for

Result List | Toggle Focus Selection Extend

is

Ctrl+Shift+Space (Result List)

In the ini file this is:

result_list_toggle_focus_selection_extend_keys=9504

That's why I showed the list of mismatched entries in the INI file

result_list_select_focus_extend_keys=9248
result_list_toggle_focus_selection_extend_keys=9504

These keyboard settings don't exist in Everything 1.4.
They have been added in Everything 1.5.

If you load your old Everything.ini from Everything 1.4 in Everything 1.5, these keyboard settings will be initialized to their default values.

what exactly is this empty def.value for "content:"?

An empty string.
-Please note: Everything doesn't use NULL values.
The content property value is always a string. -If there's no content, the string is empty.
Searching for

content:

will match any files where the content is not an empty string.

"contains:" can and should only handle a full-text search throughout the entire file data!

content: and contains: will both perform a full-text search of the file content.

If no parameter is passed to content:/contains:, then Everything will match any file that has content that is not an empty string.

To check what content Everything is seeing, include the following in your search:

add-column:a a:=GETPROPERTY($filename:,"content")

Some files might have size, but no content.
Everything will treat the file as text/plain if it is in the Tools -> Options -> Advanced -> text_plain_extensions list.
Otherwise, Everything will use the system iFilter to get file content.

For example, a jpg file might have content, but it doesn't have any text content.
So

*.jpg content:

will never return any results.

Is it possible that this forum engine doesn't support spoiler formatting in the text? Hidden text by default?
That can't be. Is the tag blocked or something?

phpbb doesn't have spoiler tags.
I don't want any hidden content on this forum.

[AntonyD]

Hi! I am using Russian translation.

It's still unclear what and how is being searched when using "content:". I followed your advice and added a column. And the VERY FIRST thing that appeared in the value was the first two characters "MZ", which are typical for executable files. And if that's the case, then ALL other files of the same type should have been displayed as a result of searching for the string "ls.exe content:" But no! ALL of them were excluded from the result.
So then WHAT exactly is being searched for, if not chars which could be interpreted as a plain human-readable text inside the file data?
And please note that due to using a single word "content" for all kinds of parts in a file, when translating into my language, I lose the thread of reasoning. For example, a sentence of the answer "Searching for content: will match any files where the content is not an empty string."
looks to me like a tautology.

[void]

Windows has a stock iFilter for exe files.
It always returns empty text for content.

You should see the expected results if you disable iFilters: (not recommended)

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  ifilter
• Select: content_ifilter
• Set the value to: false
• Click OK.

Note: If you disable ifilters, then docx/pdf content will not work.



The next alpha update will make it easier to exclude iFilters for *.exe files.
(set content_ifilter_handlers to

[{"filter":"*.exe","handler":"{00000000-0000-0000-0000-000000000000}"}]

)

[void]

Everything 1.5.0.1400a adds the option to block iFilters by using a NULL handler.

To block the ifilter for exe/dll files:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  ifilter
• Select: content_ifilter_handlers
• Set the value to:
  [{"filter":"*.exe","handler":"{00000000-0000-0000-0000-000000000000}"}]
• Click OK.

I have on my TODO list to add ansicontent, utf8content, utf16content and utf16contentbe properties.

[void]

Everything 1.5.0.1401a adds the following properties:

ansi-content
utf8-content
unicode-content / utf16le_content / utf16_content
utf16be-content
text-plain-content plain-text-content
ifilter_content

Example usage:

Code: Select all

add-column:a a:=GETPROPERTY($filename:,"ansi-content")