A need for visual aids in paths used in Search Edit box

[Thy Grand Voidinesss]

Currently users can adjust colors and the font used in the filtering box under the

Tools > Options > General > Fonts and Colors > Item > Search Edit



Unless some special unusual looking font is used that happens to have a lot of extra space around some of its special characters like semicolon, this customization option in no way alleviates the problem of readability of filtering expressions like e.g.

Code: Select all

C:\Edits\2013;D:\Edits\2013;E:\Edits\;W:\Edits\2010s;"X:\Edits Raw\2010";Z:\Edits;"C:\Edited New";"D:\Edited New";"E:\Edited New";"D:\Edited New" .123

Code: Select all

T:\Backups\2017;T:\Backups\2018;T:\Backups\2019 .abc

Code: Select all

\Music;\musikk;\muzik\;\musique\;M:\Mus\;"M:\Mus New\";"M:\Mus New - 24 bit\";"M:\Mùzyka New";"Z:\Muziko"

in a situation when user needs to omit a paths like

Code: Select all

C:\Edits New

Code: Select all

T:\Backups\2016

Code: Select all

M:\Mus Old

and thus cannot use just as simple expressions like

Code: Select all

\edit

Code: Select all

\backup

Code: Select all

\mus

Hence I propose 5 solutions:


#1] Allow for using of spaces before semicolons. Thus resulting in my examples with

Code: Select all

C:\Edits\2013 ;D:\Edits\2013 ;E:\Edits\ ;W:\Edits\2010s ;"X:\Edits Raw\2010" ;Z:\Edits ;"C:\Edited New" ;"D:\Edited New" ;"E:\Edited New" ;"D:\Edited New" .123

Code: Select all

T:\Backups\2017 ;T:\Backups\2018 ;T:\Backups\2019 .abc

Code: Select all

\Music ;\musikk ;\muzik\ ;\musique\ ;M:\Mus\ ;"M:\Mus New\" ;"M:\Mus New - 24 bit\" ;"M:\Mùzyka New" ;"Z:\Muziko"

#2] Allow for using of spaces after semicolons. Thus resulting in my examples with

Code: Select all

C:\Edits\2013; D:\Edits\2013; E:\Edits\; W:\Edits\2010s; "X:\Edits Raw\2010"; Z:\Edits; "C:\Edited New"; "D:\Edited New"; "E:\Edited New"; "D:\Edited New" .123

Code: Select all

T:\Backups\2017; T:\Backups\2018; T:\Backups\2019 .abc

Code: Select all

\Music; \musikk; \muzik\; \musique\; M:\Mus\; "M:\Mus New\"; "M:\Mus New - 24 bit\"; "M:\Mùzyka New"; "Z:\Muziko"

#3] Allow for using of spaces before and after semicolons. Thus resulting in my examples with

Code: Select all

C:\Edits\2013 ; D:\Edits\2013 ; E:\Edits\ ; W:\Edits\2010s ; "X:\Edits Raw\2010" ; Z:\Edits ; "C:\Edited New" ; "D:\Edited New" ; "E:\Edited New" ; "D:\Edited New" .123

Code: Select all

T:\Backups\2017 ; T:\Backups\2018 ; T:\Backups\2019 .abc

Code: Select all

\Music ; \musikk ; \muzik\ ; \musique\ ; M:\Mus\ ; "M:\Mus New\" ; "M:\Mus New - 24 bit\" ; "M:\Mùzyka New" ; "Z:\Muziko"

#4] Allow for defining of colors of special characters used by Everything, i.e. of [if I am not mistaken]

Code: Select all

;
"
\
/

Thus resulting in my examples with

[visualization not available]

#5] Allow for defining of colors of any characters [so that a user might incorporate them to stored items names and later on see also them clearly in filtering expressions]

Thus resulting in my examples with

[visualization not available]

All of the above 5 solutions could be implemented on a stand alone basis [e.g. just #1] or as a combination [e.g. only #2 and #4] or as whole [i.e. from #1 to #5]



They should also work with the already available workaround:

#0] Using multiple semicolons, i.e.:

Code: Select all

C:\Edits\2013;;;D:\Edits\2013;;;E:\Edits\;;;W:\Edits\2010s;;;"X:\Edits Raw\2010";;;Z:\Edits;;;"C:\Edited New";;;"D:\Edited New";;;"E:\Edited New";;;"D:\Edited New" .123

Code: Select all

T:\Backups\2017;;;;;;;;;;T:\Backups\2018;;;;;T:\Backups\2019 .abc

Code: Select all

\Music;;;\musikk;;\muzik\;;;\musique\;;;M:\Mus\;;;;"M:\Mus New\";;"M:\Mus New - 24 bit\";;;"M:\Mùzyka New";;"Z:\Muziko"

which helps only to some extent and at the side cost of loosing too much of horizontal space for all those repetitions of semicolons and making it look unaesthetic



And an additional sixth idea:

#6 Allow for adding of virtual pauses after / before semicolon - i.e. show them in Search Edit box but do not add them as eligible for selections. But that would lead to confusions when names of items would have real extra pauses in them [no matter if semicolons would still be used as separators or not] and could interfere greatly with first 5 solutions. But take a look just how readable are even the longest paths in Windows Explorer on Windows 10 clear in terms of spotting where on name of folder end end when next starts



If something similar could be [dynamically?] applied to filtering expressions in Everything it would make them easier to use and not make typo mistakes



But whatever from the above ideas might become implemented, they all should work also in concurrence with these two proposed by me adjustment to the Search Edit box: viewtopic.php?p=55905, viewtopic.php?p=55890

[Thy Grand Voidinesss]

Although I can already see a problem with my 5 solutions: what about the items that happen to have semicolons in their names?

Well solutions to this aspect would be:


A] Make it obligatory for users to use more than one semicolon, as it is more likely that a user has more items with just one of them than two or more of them next to each other. But that would not work for those items that actually do have more than one


B] Replace semicolon with rarely used sign like tilde. But that would only relocate this issue to items with

Code: Select all

~

in their names


C] Replace semicolon with an illegal character, as there is no way [?] of them showing up in names of items. The backslash

Code: Select all

/

seems to by ideal, assuming it would only be allowed [i.e. valid] to be used on the beginning of shortened path and that it would mean a beginning of search expression and not automatically beginning of a name of item. So the last example could be written [nicely] like e.g.

Code: Select all

/Music /musikk /muzik\ /musique\ /M:\Mus\ /"M:\Mus New\" /"M:\Mus New - 24 bit\" /"M:\Mùzyka New" /"Z:\Muziko"

or [more robust] like

Code: Select all

/Music/musikk  /muzik\ / musique\  /  M:\Mus\   / "M:\Mus New\"  /  "M:\Mus New - 24 bit\"  /  "M:\Mùzyka New"/"Z:\Muziko"

or [when shortened] like

Code: Select all

/Mus/"M:\Mùzyka New"/"Z:\Muziko"

[but only when] assuming a user this time does not want to omit in this search the location of

Code: Select all

M:\Mus Old

Other allegeable candidate for replacement of semicolon would be the also available on the keyboard sign of vertical bar

Code: Select all

|

but this one would be less convenient to be used on a daily basis, because in requires a combination of SHIFT+\ to be written

[void]

Please consider using | to separate paths to improve readability:

Code: Select all

C:\Edits\2013 | D:\Edits\2013 | E:\Edits\ | W:\Edits\2010s | "X:\Edits Raw\2010" | Z:\Edits | "C:\Edited New" | "D:\Edited New" | "E:\Edited New" | "D:\Edited New" .123

what about the items that happen to have semicolons in their names?

Escape ; with double quotes.

For example:

c:\windows;"c:\a;folder;with;semicolons"

[Thy Grand Voidinesss]

Good


So this

[...]
C] Replace semicolon with an illegal character
[...]allegeable candidate for replacement of semicolon would be the also available on the keyboard sign of vertical bar

Code: Select all

|

ability is already there - but as

this one would be less convenient to be used on a daily basis, because in requires a combination of SHIFT+\ to be written

I would still advocate for making it possible to also use also proposed by me

Code: Select all

/

sign for convenience of writing it. Or is perhaps backslash used in for something else or in the code of Everything, thus making it somehow too complex to be utilized also by users?


As for this

[...]
#4] Allow for defining of colors of special characters used by Everything, i.e. of [if I am not mistaken]
[...]
#5] Allow for defining of colors of any characters [so that a user might incorporate them to stored items names and later on see also them clearly in filtering expressions]
[...]

in my opinion it is still also a valid suggestion, in the never ending quest of making Everything great

[void]

Everything treats / as a path separator.
In most cases, / is treated the same as \

Allow for defining of colors of

Syntax highlighting is on my TODO list.
However, it is really difficult to do with the stock Windows controls.

Thank you for the suggestions.

[Thy Grand Voidinesss]

Everything treats / as a path separator.
In most cases, / is treated the same as \
[...]

To be precise:

Code: Select all

/

sign is a separator of paths - or - a separator of parts of path i.e. it can mark end / beginning of folder within each path, just like

Code: Select all

\

sign does?

[NotNull]

/

sign is [..] , just like

/

sign does?

???

EDIT: Original text is now changed; makes more sense


The / is also used for search commands in the searchbar -- like /fullscreen=1
The \ is not supported for these cases.

[void]

it can mark end / beginning of folder

With no search modifiers or search functions, Everything will treat / and \ as the same.

The following are treated as the same:
\windows
/windows
(folders starting with windows)

system32\
system32/
(folders ending with system32)



Most search modifiers and search functions are strict with / and \
For example, regex will not treat / and \\ as the same.

regex:c:/ will not match c:\

[NotNull]

regex will not treat / and \\ as the same.

So what is the function of the convert_regex_forward_slash_to_double_backslash setting?

[void]

convert_regex_forward_slash_to_double_backslash will convert / to \\

This has an unfortunate side effect that makes it impossible to match a scheme name with regex.
regex: will no longer be able to match a literal /

for example:
regex:ftp://

Typically, scheme names are not indexed so this shouldn't cause much concern.

[Thy Grand Voidinesss]

So because of external / remotely accessed path via e.g.

Code: Select all

ftp://

the

Code: Select all

/

sign will not have its function changed to separator - thus the

Code: Select all

|

sign will have to continue doing as such [i.e. being separator, along with the semicolon]?


If yes then I reckon this topic has run its course and there is nothing more to do but patiently wait for

[...]
Syntax highlighting
[...]

implementation

[void]

For now, to improve readability of the search, please try including more spaces around the |

For example:

Code: Select all

c:\folderA\file1.txt   |   c:\folderB\file2.txt

This is treated the same as:

Code: Select all

c:\folderA\file1.txt|c:\folderB\file2.txt

Code: Select all

c:\folderA\file1.txt;c:\folderB\file2.txt

[ChrisGreaves]

Tools > Options > General > Fonts and Colors > Item > Search Edit

Thy Grand Voidinesss, thank for once again sending off into the void and down yet-another-rabbit-hole
As you know I am long on experience but short on experience within Everything.

I had not looked at the readability of long expressions, but can see your problem from my 76-year-old eyesight and an HP15 laptop with increased resolution and smaller fonts.

I can't comment on your formatting mechanisms, but wonder if some sort of short-term quick-assembly of macros might not work?

I understood your example of "all drives C through E but not D" and some others like it. I wonder whether some of your examples might be resolved by the use of on-the-fly macros, such as we find in word-processing software. Of course, long-term stable macros would work as well.

I suggest this being mired in matters of The Preprocessing Phase(s).

If some of your constructions in the Search Edit Box can be resolved by macro-strings, would that remove some of the load?
Cheers, Chris

[NotNull]

convert_regex_forward_slash_to_double_backslash will convert / to \\

I got that far.

However, with that setting enabled, regex:c:/windows does not produce any results?

[void]

Tools -> Options -> Search -> Replace forward slashes with backslashes needs to be enabled too.

I'll change the values in the next alpha update to:
false
(use Replace forward slashes with backslashes value)
true

[DerekZiemba]

I find Notepad++ "Visual Prolog" language does an OK job making queries readable. I write them in there then paste them back to everything. You'll want to set

/paste_new_line_op=AND

so it doesn't convert multiple lines to OR conditions.
TO go from Everything back to notepad++ I paste it into notepad and format it withj Find:

\s*(#define<:[\w\-]+=#{:)\s*(.+?)\s*(#}:#>:)\s*

& Replace:

$1\n\t$2\n$3\n

Capture.PNG (228.34 KiB) Viewed 7486 times

[void]

Everything 1.5.0.1345a improves the convert_regex_forward_slash_to_double_backslash setting.

convert_regex_forward_slash_to_double_backslash can now be one of the following values:

• 2 = Convert a forward slash (/) to a double backslash (\\).
• 1 = Use the Tools -> Options -> Search -> Replace forward slashes with backslashes setting. (default)
• 0 = Disabled.

[ChrisGreaves]

... that happens to have a lot of extra space around some of its special characters ...

Hi Thy Grand Voidinesss.
Right now I would settle for a shortcut-key that would automatically expand my "and" spaces to three or more spaces.
Or for someone like me, an option to automatically expand my "and" spaces to three or more spaces.

On Saturday I decided that my three sub-folders served me better without the space characters between "Section" and "01" (see images below), so I changed them to read "Section01", "Section02", and "Section03".

Today I fired up Everything with its preloaded search string

T:\Greaves\Training\Everything\Tutorial\Section 02\ ext:doc

and was amazed to find that Everything was smart enough to ***know*** that I had renamed those three folders, and really wanted to see the documents. Please note the space character in the search string shown in this paragraph.

Indexes_08.png (58.92 KiB) Viewed 7364 times

The image above lets Windows Explorer show that my Rename commands took effect. As of Friday the folders are named without embedded spaces in the path elements.

Indexes_09.png (99.27 KiB) Viewed 7364 times

The image above shows my Result List with that old Tools, Options, General, Home search string in place. It has retained its embedded space, but the results look good to me.

Indexes_10.png (97.95 KiB) Viewed 7364 times

The image above shows the same results, but with a Search String where <spaces> that would be interpreted as the "AND" operator have been expanded - could have been automatic but I did this manually" - to draw attention to the fact that these <spaced> are NOT part of the path elements, but serve to join segments of a search string.

I have been caught by this so often in the past that I am tempted to call it a "search sting"!

I understand your call is for visibility of ALL elements, but my guess is that making this AND operator stand out might resolve half of all beginner user problems.

Cheers, Chris

[reitwal]

In my opinion a function like "include-file-list:" but for paths (maybe include-path-list:) might be useful in such cases.

[void]

Please try the ancestorfilelist1: search function.

Include the following in your search:
ancestorfilelist1:

Hold down Ctrl and click the ancestorfilelist1: text in the search box.
Add multiple folder paths and click OK.
(Everything can handle millions of paths here).

File List Slots

[reitwal]

OK, thank you!

ancestorfilelist1: works fine to restrict the results to the paths I want.
But when I do a notindexed:content: search in these paths then I get no hit while I get multiple hits when I write the same paths directly in the search field.

[void]

Unfortunately, ancestorfilelist1: currently does not support adding new results.

I have this on my things to fix list.

[Thy Grand Voidinesss]

[...]
I understood your example of "all drives C through E but not D" and some others like it. I wonder whether some of your examples might be resolved by the use of on-the-fly macros, such as we find in word-processing software
[...]

They might

I find Notepad++ "Visual Prolog" language does an OK job making queries readable. I write them in there then paste them back to everything.
[...]

But it all comes down how fast I can fly and how many moves I need to move - AKA convenience