Location, really?

[therube]

You know, some of us are stuck in the (good 'ol) days.

But, Location, really?

[Stamimail]

Let's hear what's your alternative

[horst.epp]

Location says where the file is located.
Its better than the previous Path.
Path could also mean the full path including the file name.

[void]

Thank you for the feedback therube,

It's hard to get use to isn't it...

I am trialing "Location" for now.
We shall see if it lasts..

"Location" is more descriptive than "Path".

If you want to change "Location" back to Path:

• Exit Everything (File -> Exit)
• Open your Everything.ini in the same location as your Everything.exe
• Change the following line:
  localization_strings=
  to:
  localization_strings=Location=Path;Open Location=Open Path;Co&py Location=Copy Path;Copy Location=Copy Path
• Save changes and restart Everything.

[froggie]

Just a vote for going back to path.
Path and full path are well known - since DOS days
Microsoft style guide:
https://docs.microsoft.com/en-us/style- ... ons/p/path

[malventano]

I respectfully submit another vote for going back to "Open Path".
Also recommend the entry below it be labeled as "Copy Full Path to Clipboard" so that it is a bit more different/distinguishable than the entry just above it.

If you want to change "Location" back to Path:

• Exit Everything (File -> Exit)
• Open your Everything.ini in the same location as your Everything.exe
• Change the following line:
  location_strings=
  to:
  location_strings=Location=Path;Open Location=Open Path;Co&py Location=Copy Path;Copy Location=Copy Path
• Save changes and restart Everything.

I tried this, but location_strings= was not present in either "AppData\Roaming\Everything\Everything-1.5a.ini" or "C:\Program Files\Everything 1.5a\Everything-1.5a.ini", and adding the line to either file had no effect on the behavior. Is this an issue when both versions are installed?

[void]

Thank you for the feedback everyone.

I tried this, but location_strings= was not present in either "AppData\Roaming\Everything\Everything-1.5a.ini" or "C:\Program Files\Everything 1.5a\Everything-1.5a.ini", and adding the line to either file had no effect on the behavior. Is this an issue when both versions are installed?

localization_strings*

in the Everything.ini in the same location as your Everything.exe

[raccoon]

I just like Path because it's short and easier to type than Location or Loc, but it's also a technical term that doesn't get confused with "the location of something" like describing the location of settings or the x,y coordinates location of GUI elements on screen. Path is either the path of an object or a place to walk along in nature.

Though even if Path is renamed to Location in English, it'll probably remain the same in all other translations.

[Stamimail]

Give it a month, and you'll get used to it.

In order for this discussion to be fair, it is very important to understand, what caused PATH to be replaced. An example:
Why path: is not replaced by fullpath:
"Bring Me Solutions”

[malventano]

Give it a month, and you'll get used to it.

In order for this discussion to be fair, it is very important to understand, what caused PATH to be replaced. An example:
Why path: is not replaced by fullpath:
"Bring Me Solutions”

If using 'location' in the context menu, to be consistent with the Windows search result context menu, it would need to be 'Open File(/Folder) Location' and not 'Open Location'.
...but I still believe 'Open Path' is the easier one to visualize in the menu, as is 'Copy Full Path'.

[Stamimail]

related to this topic:
https://superuser.com/questions/616021/ ... 318#854318
https://filestore.community.support.mic ... pload=true

Yes, it is not an easy decision to define in Everything terms that distinguish between the meanings:
A. Path without filename
B. Path includes filename

No matter which pair of words you choose:
1. Each word should be clear and distinguish between the meanings.
2. You should use the same terminology consistently throughout the software
3. The user will be able to type and use the terms in the search box intuitively

[void]

Everything 1.5.0.1318a reverts to Path.

[Stamimail]

Yes, it is not an easy decision to define in Everything terms that distinguish between the meanings:
A. Path without filename
B. Path includes filename

Everything 1.5.0.1318a reverts to Path.

There is no problem to define in Everything:
A = Path
B = FullPath

But please use those definitions in Everything as expected.

Please change:
Menu| Search -> Match Path
to
Menu| Search -> Match FullPath
Menu| Search -> Match Full Path


and please change the function
path:
to search only the Path column (and not the full path. path: should be different than fullpath:).

[malventano]

But please use those definitions in Everything as expected.

Please change:
Menu| Search -> Match Path
to
Menu| Search -> Match FullPath
Menu| Search -> Match Full Path

`Match Full Path` does make more sense there, at least for UI consistency.

and please change the function
path:
to search only the Path column (and not the full path. path: should be different than fullpath:).

Yeah, this also makes sense, as currently `path:` and `fullpath:` appear to do the exact same thing.

[therube]

Everything 1.5.0.1318a reverts to Path.

What? And I was just getting used to that, er, other word, whatever it was?

because it's short

While that may be a short reason, it is nonetheless very good.
You do remember things like; /BIN/, /DEV/, /LIB/, ... How about something like the (horribly awkward) "My Documents" (or "Program Files (x86)"?
(I suppose that "My Documents" is "more descriptive" then /DOC/ .)

you'll get used to it

Look up the word, Luddite.

it is not an easy decision to define in Everything terms that distinguish between the meanings:
A. Path without filename
B. Path includes filename

Is for me. I simply intermingle the two - even within the same sentence. That way, all parties remain happy.

https://www.ibm.com/docs/en/integration ... -work-path
IBM allows you to Changing the location of the work path, but not the Path of the location?

https://wiki.eclipse.org/FAQ_What_is_th ... ocation%3F
"In general, the term location represents physical file system paths, and path represents a resource's logical position within the workspace. Many people are confused by this distinction, as both terms are represented by using the IPath data type."

"Confused" is an understatement.

Stackoverflow smooths that out, The difference between Path: and Location: in Eclipse, Properties (of the project), Resource? - a little.

Path vs Location - What's the difference?
A trail for the use of, or worn by, pedestrians.
vs
A particular point or place in physical space.

For the latter, I'd need to understand "physical space"?

And the 'ol tried & true, File path formats on Windows systems.

I did a Google search for "kernighan & ritchie unix path location", & all it returned was, Does not compute?

[Stamimail]

it is not an easy decision to define in Everything terms that distinguish between the meanings:
A. Path without filename
B. Path includes filename

Is for me. I simply intermingle the two - even within the same sentence. That way, all parties remain happy.

I think it's a very bad idea to go that route.

My problem was intuitiveness, consistency and clarity.

If your problem is that "location" is not a shortened enough word, this problem can be solved by "aliases":
location: (descriptive form for beginners)
loc: (short form for advanced users)

If the problem is that "location" is not a good term, please step forward and suggest a better term.

English Windows users can check:
The term "Path" in context of Windows - what the mostly meaning used in Windows?

A. Path without filename
B. Path includes filename

[therube]

(Almost all I said was in jest .)

[Stamimail]

(Almost all I said was in jest .)

I think I told you once that jokes often fail because they are not well communicated either through writing or to non-English speakers.

[Stamimail]

What about "Parent" instead of "Path"?

[raccoon]

Parent-Name is already the name of the singular parent object, and Parent-Path is the path to the parent object (minus the parent-name).

I'm in the leave-it-alone camp.

Everything64_gHYxYjCYh2.png (10.42 KiB) Viewed 13539 times

[void]

I will consider "Parent".

Thank you for the suggestion.

I liked "Location".
It's short and descriptive enough.
Windows uses this term in Right click -> Properties -> Location.

[Stamimail]

Everything64_gHYxYjCYh2.png

Nice image.
If you asked me, I would say that the "Parent Path" of "cs-CZ\" (and of the other folders in the list) is "C:\Boot" (not "C:").

[horst.epp]

Everything64_gHYxYjCYh2.png

Nice image.
If you asked me, I would say that the "Parent Path" of "cs-CZ\" (and of the other folders in the list) is "C:\Boot" (not "C:").

I also would say this

[raccoon]

That would seem very odd, then. There is an object's Name and an object's Path. The question of this thread is simply whether to replace the word path with the word location or some other such synonym. There was never any question about whether an object's name and its path (or location) are distinct, they are. There is the concept of a full-path or object's address, but that isn't a matter on the table. There is *-Name and *-Path, and @void wants to decide whether *-Path becomes *-Location or *-Parent or *-Bandersnatch.

It would never make sense for the Parent-Path to also include the Parent-Name component, as these are discreet and isolate components. You can stitch them together, but that's a third entity called X-Full-Y, as in Parent-Full-Path.

The Parent of "cs-CZ" is "Boot", and the Path of "cs-CZ's" parent "Boot" is "C:"... thus Parent-Path is "C:".

Now you know.

(Please leave path alone. It has done nothing to you. Path loves you and you love path.)

[Stamimail]

The claim is that there is confusion in terminology:
"Path" in Windows = what you call FullPath (There is no such a term FullPath in WIndows. This is "Path".)
The term "Path" was used in Everything by mistake to describe Path without filename, and Everything now should choose other term for this.

(Please leave path alone. It has done nothing to you. Path loves you and you love path.)

I have already presented the problem.

[raccoon]

"Path" in Windows = what you call FullPath (There is no such a term FullPath in WIndows. This is "Path".)

I do believe this to be an inaccurate assessment. There are numerous places in windows and programming languages within windows that use "path" and "fullpath" as I described them. VisualBasic, Javascript, Win32API, etc. It has always been this way since the dawn of Windows 32. According to Microsoft, the word FullPath comes from "Fully Qualified Path" which includes the path and filename.

https://learn.microsoft.com/en-us/windo ... lpathnamea

https://learn.microsoft.com/en-us/windo ... ing-a-file

The only thing @void ought consider doing is including *-fullpath columns for objects, while leaving the *-name" and *-path columns as they are. Ie: Parent-Name, Parent-Path, and Parent-Fullpath.

[froggie]

Code: Select all

"Path" in Windows = what you call FullPath (There is no such a term FullPath in WIndows. This is "Path".)

That is not correct. Microsoft does distinguish between Path and FullPath.
From the Microsoft style guide:

Use path to refer to a drive and any folders below the root directory. When a path also specifies a file, use full path.
In command syntax, use path to represent only the folder portion of the full path:

https://learn.microsoft.com/en-us/style ... ons/p/path

[raccoon]

^ what froggie said.

[void]

Thank you for the feedback everyone,

Whatever I use will sound vague, confusing or too long:

"Parent Path"
"Parent Parent"
"Parent Location"
"Parent Path Part"

In the next alpha update I will look into clarifying "parts of the filename" in Help -> Syntax

The only thing @void ought consider doing is including *-fullpath columns for objects, while leaving the *-name" and *-path columns as they are. Ie: Parent-Name, Parent-Path, and Parent-Fullpath.

I will add Parent-Full-Path, Short-Full-Path and Parse-Full-Path properties.
Thank you for the suggestion.

[Stamimail]

"Path" in Windows = what you call FullPath (There is no such a term FullPath in Windows. This is "Path".)

That is not correct. Microsoft does distinguish between Path and FullPath.
From the Microsoft style guide:

I am happy with your sources. But we still have to ask:
This is from a programmers point of view.
What about the end-users point of view? (Did the UI\UX team of Windows use the term "Path" in the same meaning as the programmers? What the meaning of Path in Windows UI? Can we find the term "FullPath" or "Fully Qualified Path" in Windows UI?)


The following question about the Search menu is still on the table:

Also, why Ctrl+U is called "Match Path" instead of "Match Fullpath"?

[raccoon]

The following question about the Search menu is still on the table:
Why Ctrl+U is called "Match Path" instead of "Match Fullpath"?

Because all of the checkmarks under the Search menu are inclusive, like Match Diacritics. The Name is always searched, and Match Path merely includes the Path. So, Match Fullpath would match the Name twice?

If programmers use one set of phrases among themselves, and another set of phrases in "mixed company" or "around users", then THAT'S where confusion begins. Never buy into soft language.

[void]

Because all of the checkmarks under the Search menu are inclusive

This is how I have always seen the option too.
Match Path means match the Name and Path.



Everything 1.5.0.1330a changes the following properties names:

• Short Path => Short Full Path
• Parse Path => Parse Full Path
• Display Path => Display Full Path
• File List Path => File List Full Path

I didn't add Parent-Full-Path as this is the same as Path and I am trying to avoid duplicate properties.



I have added filename terminology to Help -> Syntax

Code: Select all

Filename parts:
	Full Path:	C:\folder\file.txt
	Name:		file.txt
	Path:		C:\folder
	Stem:		file
	Extension:	txt

[Stamimail]

Great. After all these clarifications, I think there is one thing left to fix:

I was trying to search the path column. (without name column)
path: was the first attempt to get results from the path column only. I think it's the most intuitive.

The search function "path:" still behaves like "fullpath:". It should match the path column only. (consistency: same behavior for all column header names)

[raccoon]

Great. After all these clarifications, I think there is one thing left to fix:

I was trying to search the path column. (without name column)
path: was the first attempt to get results from the path column only. I think it's the most intuitive.

The search function "path:" still behaves like "fullpath:". It should match the path column only. (consistency: same behavior for all column header names)

Again, search modifiers are inclusive, not exclusive. The path: modifier includes the Path in addition to the Name. We went over this.

[Stamimail]

I hardly agree with "all of the checkmarks under the Search menu are inclusive", you want me to also agree that the search functions will also be like that.

I can't agree with this, losing both intuitiveness and consistency.

For example:

Code: Select all

ext:mp3 path:download artist: album:

I expect to use "path:" exactly the way I use "artist:" and "album:" or any other "column-name:".
"download" text should be highlighted/searched only in the Path column, and not in the Name column.

[raccoon]

Dear Stamimail,

You aren't going to find artist: and album: nor pathpart: under the Search menu.

Sorry about the ambiguity between path: and pathpart: where the former is representative of the Search menu option, while the latter is representative of an object's property or column data. artist: and album: and pathpart: enable you to search for content of a specific column, verbatim, while the predecessor (older) modifier path: belongs in the category of case: and diacritics: and similar search modifiers.

It's different. Sorry about the sordid evolution of this software. path: equates to basename: and pathpart:, ie, Name and Path, ie, Fullpath. This is because Name is ALWAYS assumed (a default search modifier) and cannot be turned off.

[void]

What might help here is a search tooltip:

path: is typed into the search box.

A tooltip is shown:

Search modifier usage:
path:<search term>
The search term will match the name and path instead of just the name.
Example:
path:abc123
path:"abc 123"

(Maybe <search-term> could be clickable which describes a search term)



fullpath: is typed into the search box.

A tooltip is shown:

Search function usage:
fullpath:<text>
Search for the <text> anywhere in the full path and name.
Example:
fullpath:c:\windows\notepad.exe
fullpath:"C:\Program Files\Everything\Everything.exe"



pathpart: is typed into the search box.

A tooltip is shown:

Search function usage:
pathpart:<text>
Search for <text> any where in the path without the name.
Example:
pathpart:c:\windows
pathpart:"C:\Program Files"



size: is typed into the search box.

A tooltip is shown:

Search function usage:
size:<size>
Search for files/folders with a matching <size> in bytes.
Use an optional KB/MB/GB suffix.
Use operators > >= == != < <= ..
Example:
size:1mb
size:10mb..100mb
size:>100mb



Search tooltips are on my TODO list.

[froggie]

Now I am confused.

pathpart is clear, but what is the difference between path and full path? They are described somewhat differently but they both yield the same results for all cases I have tried. What would be an example of where they would give different results?

[raccoon]

"Full Path", full-path:, is just another column under Add Columns that you can search from within.

You don't have to use it, but there's no reason to prohibit using it.

[void]

path: and fullpath: are essentially the same.

path: is a search modifier and fullpath: is a search function.



There are some subtle differences, which will probably make things more confusing by trying to explain them..

Search modifiers can be combined, eg: path:regex:case:^FOOBAR
Some functions use the path: search modifier, eg: path:fileexists:\1
If no search function is specified, Everything will search the name and path (instead of just the name)

with path: you can do things like:
path:len:>259

path: here means compare against the name and path.
len: could be considered the function here. (although technically len: is also a search modifier)



with fullpath: you can do things like:
fullpath:==parsefullpath:
column1:=fullpath:



I agree that the name path: is confusing.
path: matches the name and path vs the Path column which is only the path part (without the name).

One option is to change the path: search modifier name.
However, this will break backwards compatibility.

Another option is to change the path column name.
This was not well received.

Tooltips might help to clarify the path meaning.

Using path: and having it match the name part too shouldn't upset too many users.

[raccoon]

I feel a future in Everything where the Name search can be toggled off, and a selection of different columns can be turned on as the default search. Name, Path, Album, Artist, Director, Producer, Content, etc. Maybe "Search all visible columns" or "Search all indexed properties." ¯\_(ツ)_/¯

[void]

It's on my TODO list
It probably won't make it for an Everything 1.5 release.

I need to work out how to solve size/date/etc.. searches, is searching for just >10mb enough? you won't need size: anymore...
today would search filenames, or files/folders from today.

[raccoon]

Just go with whatever you think would feel most natural to most users. If it's a date-type search term, then I guess any indexed property of date-type would qualify... whether Created, Modified, Accessed, Changed, Taken, (Content Created), (Media Crated), etc. If the search term is a size-type, then search all of the indexed properties of size type casting. Highlighting would show why each result matched.

This said, how would you feel about a column in the Add Property dialog that displays the type casting of each data type? Text, Number, Boolean, Size, Date?

[void]

I will consider a toggle-able column to show the property value type.

Thank you for the suggestions.