[Suggestion]: Use forwardslash everywhere

[DerekZiemba]

To use forward slash everywhere so that backslash can be used for escaping.

• Display all paths with forward slash
• When a path is pasted, auto-convert backslash to forward slash (unless backslash is escaped with backslash in front of it)
• When a path is copied, use the forward slash representation.
  • Already works fine in Explorer
  • Works fine in every shell/terminal except cmd & that's being replaced by pwsh anyway.
  • Works in browsers
  • As a dev, I won't have to manually convert to forwardslash when pasting into a JSON file, etc.
• Perhaps, to simplify things, go as far as making the internal path representation always be forward slash & converting as needed when interacting with win32 APIs.

Once that's settled, do what every other normal program does and use backslash as an escape hatch. Could then potentially open up more advanced globbing, with `\` escaping the literal representation

----------------------
However In the meantime, simpler things:

• Add a setting to copy paths with forward slashes.
  Or to copy with backslashes already escaped, ie: `C:\\Windows\\System32\\some\\folder`
• Some way to glob for numbers.
  • I'd suggest `#` but that's a valid path character.
  • `:` is unused but may conflict with the macro/property system.
  • `< | >` already work nicely (in the search bar, not sure if it works everywhere though like the Index Exclude List).
  • This leaves `"` as the only remaining invalid path character, but is already used to group things with spaces in them.
    But... If there was an escape char `\`.... a lot of options open up

[horst.epp]

WE are in a Windows environment, which clearly uses \ for paths.
There are enough other ways to escape some characters without changing fundamental things.

[void]

I have put on my TODO list to add an option to convert \ to /

I will consider more globbing options and \ escaping.

Thank you for the suggestions.

[therube]

Just to note, some places/actions in Everything are already ambidextrous (accepting either or) /\.

When a path is copied, use the forward slash representation.

For a copy operation, was there already an option for that?
Such that display would be \, but paste would be / (or was that something different). [Must have been different. Nope, it's there.]

file_copy_full_path_with_forward_slashes_keys=

Works fine in every shell/terminal except cmd

Suppose it's possible you could run into other third party programs that, lets say, use funky operations for Open boxes or whatnot where / might not be accepted, or where a programs command-line options will not work with a path of, /paths/to.somewhere/abc.txt.

globbing

Can be tricky (to get it right).


And \\ can be ugly for one to look at (well, at least for me).

image.png (305.16 KiB) Viewed 281 times

[meteorquake]

I suspect what's needed is a universal setting that affects everything, that can then be tied to a shortcut (directly or via bookmark).
So whenever you need / or \\ or any other format you hit the shortcut and everything changes to that. You do whatever you need e.g. copying then hit a shortcut to return back to your default preference. Doing the same shortcut twice could toggle.
d

[void]

For a copy operation, was there already an option for that?
Such that display would be \, but paste would be / (or was that something different). [Must have been different. Nope, it's there.]
file_copy_full_path_with_forward_slashes_keys=

Use the UI to set a hotkey for File | Copy Full Path With Forward Slashes:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Keyboard tab on the left.
• To the right of Show commands containing, search for:
  copy
• Select: File | Copy Full Path With Forward Slashes
• Click Add....
• Press a new keyboard shortcut (for example: Ctrl + Shift + C) and click OK.
• Click OK.

A few issues I've found with converting \ to / are:
The shell doesn't like / (path to PIDls APIs don't work, so things like context menus are broken)
Windows doesn't like // UNC paths.
Common open dialogs do not like / in paths.

If I do add a option to convert \ to / it will be a display and copy option only.

[void]

There is a wildcard: search modifier that offers:

* = Matches any character zero or more times.
? = Matches any single character (including / or \).
# = Matches any single digit (0-9).
[ ] = Matches any one of the characters specified in the set.
[! ] = Matches any one character that is not specified in the set.
\ = Escape the following character. C escapes supported. (treat the following character as literal)



-I have put on my TODO lists to treat / and \ as the same when searching filenames with wildcard:

[DerekZiemba]

WE are in a Windows environment, which clearly uses \ for paths.
There are enough other ways to escape some characters without changing fundamental things.

Such as? Invalid filename characters are ` \ / : * ? " < > | ` so you pretty much have to pick from that set.

Just to note, some places/actions in Everything are already ambidextrous (accepting either or) /\.

When a path is copied, use the forward slash representation.

For a copy operation, was there already an option for that?
Such that display would be \, but paste would be / (or was that something different). [Must have been different. Nope, it's there.]

file_copy_full_path_with_forward_slashes_keys=

Ahh, I missed that. It doesn't show up in Options -> Advanced menu. But I do see it in the config file.
EDIT: So that's just a hotkey setting with the value being a bitmask of the form

(InResultList<<14) | (InSearchEdit<<13) | (WinKey<<12) | (Shift<<11) | (Alt<<10) | (Ctrl<<9) | (255 & VK_KEY)

Works fine in every shell/terminal except cmd

Suppose it's possible you could run into other third party programs that, lets say, use funky operations for Open boxes or whatnot where / might not be accepted, or where a programs command-line options will not work with a path of, /paths/to.somewhere/abc.txt.

The issue I most often run into is actually the opposite, with most programs requiring forward_slash. If not, usually the app will use Win32 controls which already supports forward_slash.

There is the following settings. I have them enabled for consistency & to make sure my macros/filters/defined functions don't run into bugs (I've had issues before).

convert_forward_slash_to_backslash=1
convert_regex_forward_slash_to_double_backslash=1

I'd prefer options for the opposite though, akin to:

convert_backslash_to_forwardslash_onpaste=1
convert_backslash_to_forwardslash_oncopy=1
display_paths_using_forwardslash=1

or, using the existing setting keys:

convert_forward_slash_to_backslash=2 // where 2 = convert the other direction
convert_regex_forward_slash_to_double_backslash=0 // no touchy my regexpressions

[DerekZiemba]

There is a wildcard: search modifier that offers:

* = Matches any character zero or more times.
? = Matches any single character (including / or \).
# = Matches any single digit (0-9).
[ ] = Matches any one of the characters specified in the set.
[! ] = Matches any one character that is not specified in the set.
\ = Escape the following character. C escapes supported. (treat the following character as literal)

-I have put on my TODO lists to treat / and \ as the same when searching filenames with wildcard:

Ahh, I had no idea that modifier changed behavior in that way. I've always assumed there were always wildcards, just limited to `*`, `**`, & `?` and that the modifier was more of a way to toggle the behavior on & off. I had no idea it expanded the wildcard matching.

That pretty much took care of my wildcard use case. Awesome!
I won't have to rely on regex as much. BTW, are there any perf benefits to wildcards vs regex? Or is it just converted to regex behind the scenes anyway?

[meteorquake]

I can say from VBA that the simple wildcard "Like" function is vastly faster than the Regex function, which becomes important when it has to be applied millions of times. I have a vague memory of measuring it many years back and it being 10x as fast although the "Like" function was a direct part of the language whilst the Regex was used via an object although that shouldn't have accounted for the speed difference. d

[void]

Everything has it's own wildcard engine.

regex:^foo.$ on 1 million files: ~0.039 seconds
wildcard:foo? on 1 million files: ~0.002 seconds

regex:f.*o.*o on 1 million files: ~0.039 seconds
wildcard:*f*o*o* on 1 million files: ~0.012 seconds

You might see better regex performance if you use 10 or more *'s