Future Safe Virtual Folder Syntax

[admin]

To complete the Tags & Comments feature (and some other loose ends like "Search Results Caching" and so-(but-wrong)-called "Drop Stacks") I will add Virtual Folders (VFOs).

Now I meditate about a Future Safe Virtual Folder Syntax. Nobody knows what future file systems may emerge and which syntax they will support to reference items, so I try to use a syntax that is not likely to clash with anything in the future. OTOH, of course, it should be simple. Here are six possible ways:

Referencing a cached item list in C:\myfiles.txt:

Code: Select all

dat:C:\myfiles.txt
dat>C:\myfiles.txt
dat=C:\myfiles.txt
dat:\C:\myfiles.txt
dat::C:\myfiles.txt
dat:>C:\myfiles.txt

Referencing all items tagged "blue":

Code: Select all

tag:blue
tag>blue
tag=blue
tag:\blue
tag::blue
tag:>blue

Thanks for comments an ideas!

[j_c_hallgren]

Personally, of those 6 choices, I see the simple "=" as the cleanest, as it is unique and also simple to understand...my second choice would be the single ">".

[admin]

Personally, of those 6 choices, I see the simple "=" as the cleanest, as it is unique and also simple to understand...my second choice would be the single ">".

Yes. Unfortunately of all six proposals "tag=blue" is ambiguous because you could have a subfolder named "tag=blue" under the current path.

[jacky]

Well, AFAIC I think my "natural" pick would be tag:blue
I find it pretty clear, and since we're talking about locations here, just like there's a <drive letter>:<folders> we would now have <element>:<definition> kinda syntax, where later on there could be other things added to "tag" and "dat" Easy, simple, and makes sense (to me).

Oddly enough, I was wondering whether for the later, there could be a special case such as dat:<myfiles.dat as that's usually (or, to me at least) on command-line a way to symbolize that data will be read/imported from a file, as opposed to >file.ext meaning writing/exporting into it. But that's probably a bad idea... simpler to keep things with the same syntax for both, so dat:c:\myfiles

[admin]

Well, AFAIC I think my "natural" pick would be tag:blue

Yep, that was also my first pick. Later I started thinking about it. But like you, I still don't see a problem with it.

[j_c_hallgren]

It wasn't the "tag:blue" that influenced my choice, but the "dat:C:\myfiles.txt" as the ":" is then used more than once for different things and doesn't immediately jump out as the delim between the two parts...and I'll admit that I had forgotten that "=" could be used in filenames. I thought it was restricted.

[jacky]

Okay, back on this I have a question I thought I'd throw at you IIRC you said we would be able to add such virtual locations to the (Mini)Tree, any ideas as to how this will be done ? My question really being about giving such locations a "name" because I wouldn't want my node to say "tag:blue" or "dat:d:\some\folder\files.dat" but to use some kind of label/caption.
Ideally, we could even then use that label afterwards to go there directly (from AB/Go To) instead of having to use the "definition" (dat:d:\some\folder\file.dat)

[admin]

Okay, back on this I have a question I thought I'd throw at you IIRC you said we would be able to add such virtual locations to the (Mini)Tree, any ideas as to how this will be done ? My question really being about giving such locations a "name" because I wouldn't want my node to say "tag:blue" or "dat:d:\some\folder\files.dat" but to use some kind of label/caption.
Ideally, we could even then use that label afterwards to go there directly (from AB/Go To) instead of having to use the "definition" (dat:d:\some\folder\file.dat)

I'm thinking about two special nodes:

(1) Tags\, with subfolders "blue", "red", etc.

(2) Stacks\ (or so), with subfolders corresponding to all files found in a new app data subfolder "stacks\".
So if you have a file list c:\progs\xy\data\stacks\files.dat, then you would have a Tree node
Stacks\files, identical to the location dat:c:\progs\xy\data\stacks\files.dat.
Any file lists outside <xydata>\stacks\ would not have a Tree representation.

[jacky]

I'm thinking about two special nodes:

(1) Tags\, with subfolders "blue", "red", etc.

(2) Stacks\ (or so), with subfolders corresponding to all files found in a new app data subfolder "stacks\".
So if you have a file list c:\progs\xy\data\stacks\files.dat, then you would have a Tree node
Stacks\files, identical to the location dat:c:\progs\xy\data\stacks\files.dat.
Any file lists outside <xydata>\stacks\ would not have a Tree representation.

Yeah, sounds good, plus as with scripting we could then use dat:foobar instead of dat:<xydata>\stacks\foobar.dat so that's good too

However, seeing this I'm wondering whether a different syntax wouldn't be better then, such as, to use one of your proposal, tag:\blue -- just so that it has the same usual "look" of a parent/child relationship, as will be done on Tree ? Knowing this, I think it would make more sense (especially since with subfolders we'd get tag:\blue\subfolder)

[admin]

I'm thinking about two special nodes:

(1) Tags\, with subfolders "blue", "red", etc.

(2) Stacks\ (or so), with subfolders corresponding to all files found in a new app data subfolder "stacks\".
So if you have a file list c:\progs\xy\data\stacks\files.dat, then you would have a Tree node
Stacks\files, identical to the location dat:c:\progs\xy\data\stacks\files.dat.
Any file lists outside <xydata>\stacks\ would not have a Tree representation.

Yeah, sounds good, plus as with scripting we could then use dat:foobar instead of dat:<xydata>\stacks\foobar.dat so that's good too

However, seeing this I'm wondering whether a different syntax wouldn't be better then, such as, to use one of your proposal, tag:\blue -- just so that it has the same usual "look" of a parent/child relationship, as will be done on Tree ? Knowing this, I think it would make more sense (especially since with subfolders we'd get tag:\blue\subfolder)

I'm not sure if I want to do that. These are virtual folders, not virtual drives. Also the xxx:\ format might collide with things of the future (one day we will break the 26 drive letter wall...).

And, "tag:\blue\subfolder" ??? What subfolder? You cannot create subfolders here, as far as I'm concerned.

[jacky]

I'm not sure if I want to do that. These are virtual folders, not virtual drives. Also the xxx:\ format might collide with things of the future (one day we will break the 26 drive letter wall...).

Well, yes, but dat:\foobar would represent just that, a virtual folder names foobar. I see the drive analogy though - at first I had used :tag\blue and not tag:\blue but changed to go for one of your proposal. But tag:blue is fine.

And, "tag:\blue\subfolder" ??? What subfolder? You cannot create subfolders here, as far as I'm concerned.

hmmm, you mean we won't be able to browse around inside a virtual folder? So if a folder is tagged blue, going to tag:\blue would not list it as a subfolder on Tree, and dbl-clicking it on List wouldn't have us to go in there ??

[admin]

And, "tag:\blue\subfolder" ??? What subfolder? You cannot create subfolders here, as far as I'm concerned.

hmmm, you mean we won't be able to browse around inside a virtual folder? So if a folder is tagged blue, going to tag:\blue would not list it as a subfolder on Tree, and dbl-clicking it on List wouldn't have us to go in there ??

How would that work? Tagged folders are full path. So you would have a tree node MyComputer\Tags\blue\C\Folder\SubFolder\TaggedFolder?

No, Tags\ and Stacks\ will just list the flat contents (defined by tag or by file in <xydata>\stacks\). When you dbl-click any contained folder you will browse to its original location just as if opening a LNK.

[jacky]

How would that work? Tagged folders are full path. So you would have a tree node MyComputer\Tags\blue\C\Folder\SubFolder\TaggedFolder?

No, I was thinking of simply MyComputer\Tags\Blue\TaggedFolder -- Same way it work with junctions for example, or any such thing.

Seems both very simple & natural to me. And I have to say, it would be a real disappointment to me if this wasn't supported. What's the point of having a virtual folder if it's not a folder, with subfolders? Why have it on tree if it we can't have subfolders? Then it's just a link, a favorite, a catalog item, not a (virtual) folder/location...

[admin]

How would that work? Tagged folders are full path. So you would have a tree node MyComputer\Tags\blue\C\Folder\SubFolder\TaggedFolder?

No, I was thinking of simply MyComputer\Tags\Blue\TaggedFolder -- Same way it work with junctions for example, or any such thing.

Seems both very simple & natural to me. And I have to say, it would be a real disappointment to me if this wasn't supported. What's the point of having a virtual folder if it's not a folder, with subfolders? Why have it on tree if it we can't have subfolders? Then it's just a link, a favorite, a catalog item, not a (virtual) folder/location...

But you could have any number of collisions/same-names. E.g. if I tag my 120 "Code" folders blue or red for some reason, then I would have 75 blue "Code" folders under MyComputer\Tags\Blue\ and 45 red "Code" folders under MyComputer\Tags\Red\. Such a tree is useless, ain't it?

[jacky]

But you could have any number of collisions/same-names. E.g. if I tag my 120 "Code" folders blue or red for some reason, then I would have 75 blue "Code" folders under MyComputer\Tags\Blue\ and 45 red "Code" folders under MyComputer\Tags\Red\. Such a tree is useless, ain't it?

Well you're free to do anything you want! Just because in one situation it doesn't seem very useful doesn't mean the entire thing is pointless. I mean, isn't MiniTree useless if I fully expand all my drives? Yeah, probably. Does that mean MiniTree in itself is useless? Maybe not...

Besides, if you're on MiniTree you can decide which of the "Code" folders to have on Tree, and then it could became useful again. (Or, if they were all "merged" into one single folder "Code" then it could become interesting... )
And imagine you tag "blue" a bunch of folders (different names) all in different locations/drives/etc Maybe it could be useful to be able to easily have them all under the same node on tree, just for easier browsing, D&D operations, ...