'hide files' option

[admin]

So, what about

Code: Select all

!*|a*

to show no files, and only folders starting with an "a" then? You know, to be complete

Yes, I've seen the hole the pattern. But isn't there a certain beauty in imperfection?

IOW: I'll only apply it if someone shows me a convincing use case for this.

(Frankly, even the *| ... part is pretty far out. When do you want to see only folders in the list??? Hey, there's a Tree for this! I already removed the examples from woznu.)

[j_c_hallgren]

The more I read, the more confused I'm getting...
Bear with me...please...

So using this as basis:

Code: Select all

\|a* = Show all folders and all files beginning with a
\|!* = Show all folders
*|a* = Show all files and all folders beginning with a
*|!* = Show all files

And the stmt that "the inversion operator is only implemented for the whole expression, not for each term", how does this work for ex 2 & 4 above? Since the "!" is not the first char, but is part of what appears to be the 2nd term...ok?

Now if "\" represents all folders, then where do we put a unique folder filter? And how do we explicitly describe it as such? Or the no-folders criteria? Because the pipe is defined as "or", true? That's why having the \ be a prefix defining the folder selection instead, with an implied wildcard seems to make sense...so as I wrote, \| would be equal to \*|.

As is now, given that: \|!* = All folders -or- not all files
Using that layout, I would thus read *|a* = all files -or- all files beg with a
Which makes no sense, because how did the folder filter now jump to the other side of the pipe?
And then *|!* = all files -or- not all files
Again non-sensical, but no way to tell which is which, IMO...plus it uses the negation as an item term, not the whole expression.

The latest variant example !\|*.txt would have to be thus interpreted as: NOT (All folders -or- txt files)
Which wouldn't get you TXT files but all non-TXT files and no folders.
But using ! as the non-folder wildcard (yes, an exception), via \!|*.txt would get you TXT only, and still be easily readable as to intent.

[jacky]

jc, I think you are missing one little fact : while the pipe is usually a sign for OR yes, as you describe, and the ! usually the first character of the pattern, things are different here : We have two prefixes that have special meaning :

Code: Select all

\| : means show all folders
*| : means show all files

This is why a pattern such as

Code: Select all

\|!*

will show all folders : the prefix means show all folders, then we have a "regular" pattern - now applied to files only - that means show nothing, so here no files. Hence show all folders, no files. Same goes for the #4, only the other way around.

[j_c_hallgren]

jc, I think you are missing one little fact : while the pipe is usually a sign for OR yes, as you describe, and the ! usually the first character of the pattern, things are different here : We have two prefixes that have special meaning :

Code: Select all

\| : means show all folders
*| : means show all files

It wasn't really that I was missing it totally..it was that I found the resulting syntax quite confusing! And figured that I might not be the only one, ok?
Because if it were a true prefix, then I'd expect it would more likely be \||*.txt, see? As I read it as two operators combined, with \ for all folders plus a | pipe for the "or".

And it's the use of the *| that really makes it confusing, IMO, since both of these already are extensively used for other things.
I was simply trying to find a way that could be easily read without knowing that \| and *| are special here, but knowing only that \ represents a folder, which makes sense.

And then my idea of \!|*.txt would be read as: All folders=not -or- *.txt.
Yes, that is a deviation from the normal, but it's thus limited to that one char in that one case, and isn't that difficult to follow.

So that one would always have folders spec, if any, as the first item marked by a leading \, and if there was a \, it would be terminated by | if any file specs follow.

Thus \a* would get only folders starting with a, which is a simpler form of TheQwerty's example.
And !\a* would negate that, giving everything but those folders.

[jacky]

It wasn't really that I was missing it totally..it was that I found the resulting syntax quite confusing! And figured that I might not be the only one, ok?
Because if it were a true prefix, then I'd expect it would more likely be \||*.txt, see? As I read it as two operators combined, with \ for all folders plus a | pipe for the "or".

Well, no. I mean it seems to me you're trying too hard and complicating things where really there isn't a need for it. The prefix is indeed \| including the pipe sign, but just go with it, and that it "reads" or means "is a folder, or" So if you want all folders and text files, you use indeed \|*.txt which then basically reads "is a folder, or is a text file." I don't see why this would be particularly confusing, it's actually quite simple and in the logic of how things work, I feel.

The same goes for *| only that one reads/means "is a file or". So you can use either one of those 2-chars prefixes, and then use a "standard" pattern as per XY's rules for VF. I find that less confusing that other syntaxes that would for example see the ! prefix not work the same or mean the same thing depending on how you use it.

Simply look at *| a minute : any VF starting like that is "wrong," since it makes no sense to ask to show everything and, whatever comes next, since you already included everything. So there can't be confusion with any other VF or anything, it has to have a special meaning, and it reads simply "is a file or" much like its brother \| for folders. So the pipe sign, while part of the prefix, still has its usual meaning.

[j_c_hallgren]

I mean it seems to me you're trying too hard and complicating things where really there isn't a need for it.

I'm just trying to make it easy for the beginner to follow it, and not just users like us, ok? Hey, if I'm not seeing it clearly, what about the user of just one week? So sometimes what seems complicated for us makes it better for a newbie! I'm trying for a balance between the two.

The prefix is indeed \| including the pipe sign, but just go with it, and that it "reads" or means "is a folder, or" So if you want all folders and text files, you use indeed \|*.txt which then basically reads "is a folder, or is a text file." I don't see why this would be particularly confusing, it's actually quite simple and in the logic of how things work, I feel.

And that part right there...I have no issues with at all!

The same goes for *| only that one reads/means "is a file or". So you can use either one of those 2-chars prefixes, and then use a "standard" pattern as per XY's rules for VF. I find that less confusing that other syntaxes that would for example see the ! prefix not work the same or mean the same thing depending on how you use it.

This is where I have the real problem as I've tried to explain...I see * and think: wildcard...I think: folders first, then files based on path...I see \| and know that's: all folders...so what on earth based on those three facts would make me think that *| would mean all files?
That's in addition to the reasons TheQwerty listed.

Simply look at *| a minute : any VF starting like that is "wrong," since it makes no sense to ask to show everything and, whatever comes next, since you already included everything. So there can't be confusion with any other VF or anything, it has to have a special meaning, and it reads simply "is a file or" much like its brother \| for folders. So the pipe sign, while part of the prefix, still has its usual meaning.

I'd say that's part of the problem...that *| looks wrong and why should I think of that having a special meaning here? Consistency really helps...and having the filter at times be in the folder/file order and other times in file/folder order, to me, really adds to confusion..

And as TheQwerty has ponted out...what about the case where a user wants folders beginning with J or files beginning with H? How would that work? Can that be handled right now? I don't recall that it can...if so, how?

But using the idea of always prefixing the folder pattern with a \, and ending with either end-of-pattern or |, then one could have \J*|H* and that would be easily seen as J folders -or- H files, right? And this woud be consistent with existing \| as that is an implied \*|.

And then the absence of any trailing | after the initial pattern would mean that it's strictly for folders, though a trailing | could be used or required.

The only issue then is negation...that would have to handled separately, so that the ! applies at the folder and the file portion, so that !\J*|H* would be: No J folders -or- all H files, and \J*|!H* would be All J folders -or- No H files...which would thus permit !\J*|!H* being No J folders -or- No h files.

I'm not trying to overthink this, but looking at it as it is right now, I don't see how a new user is going to follow it when the pattern flips between folder|file and file|folder, as I'm certainly not used to that latter sequence, and I think very few people would think of it either.

Using a leading \ to indicate this is the folder pattern makes sense, given that it's the typical path delim, and always having folder pattern first (if any) followed by folder pattern(s) (if any) seems foolproof in being understood by anyone, IMHO.

I'd really like some follow-up from TheQuerty or others, as I'm still trying to look at this objectively and realize that just because we've got things set one way right now (ie *|), it may not be the ultimate ideal.

[TheQwerty]

j_c_hallgren, to be clear I wasn't suggesting a definitive "folder|file" usage. Though it wouldn't be a bad idea to introduce something like "file pattern||folder pattern" (this way keeps backwards compatibility better), but I don't think it's the ideal long-term solution.

The same goes for *| only that one reads/means "is a file or".

Actually this is all I needed to hear. I hadn't been thinking about it in that manner, but when I do it does make good sense.

I can accept the usage of "\|", "*|" and "!\|" based on jacky's description of them, for now...


But all of this shows that the holes and flaws in the current implementation aren't making it beautiful.
The VF engine is getting to the point where it could use a rewrite and an improved syntax. Perhaps later rather than sooner, but it needs to happen.

A few things:

• Needs the ability to define separate patterns for Folders or Files.
• It's very irritating that the inversion operator can only be applied to the whole expression and thus can't be mixed with other patterns.
• It's been requested before but it would be ideal to be able to filter on the various item stats (dates, attributes, sizes).
• I'd love to see a way to add (and perhaps subtract) from the current VF via quick VF. Especially now that the address bar doesn't show the applied patterns.

The syntax I suggested, was based on the current syntax's flaws, so it may not be ideal for the future. However, I do think a new syntax will be needed and the improvements would make it acceptable to break backwards compatibility, if required, when it happens.

[graham]

jc - I see your thinking and agree it is confusing especially so to someone who does not want to search out the correct way to achieve such filters. I think the only and simplest way round this is for Don to enhance the examples shown in the Set Visual window to explicitly include the special use of 2 prefixes so that it is immediately clear. As it is the current examples will lead to the confusion you describe, so ....

[j_c_hallgren]

j_c_hallgren, to be clear I wasn't suggesting a definitive "folder|file" usage. Though it wouldn't be a bad idea to introduce something like "file pattern||folder pattern" (this way keeps backwards compatibility better), but I don't think it's the ideal long-term solution.

A file|folder seq isn't needed for backwards compatibility IF we, IMO as expanding on curr syntax, simply use the "\" as a prefix to folder pattern(s)...since the absence of that \ thus makes it a folder spec/pattern, right?

So any existing patterns would still work just fine...as would \| or !\| but the only one that wouldn't is the quite new *| so before that gets too cemented in place in everyone's brain is the ideal time for change.

I'm suggesting a folder|file seq mostly because it's what is used in almost all cases and is the best known...now having the \ as leading indicator of a folder spec could allow it to be done in the reverse, such as *.txt|\|

And as long as the negation/inversion can be applied to either folder or all file or both, I think we have, for now, a workable solution.

[admin]

Hmpf. Much talk about what? Let's see a real world example that you cannot (or only badly) achieve with the current syntax, and then propose a better syntax for this example.

[j_c_hallgren]

Hmpf. Much talk about what? Let's see a real world example that you cannot (or only badly) achieve with the current syntax, and then propose a better syntax for this example.

I know it's a lot of text to read...and believe me, it took me a while to write it also with my vision...so I would say that my proposed syntax is already fully described in my 3 most recent posts made before your above post...so this is obviously an issue that I feel strongly about and is likely the one that I've spent this much effort on in quite a while.

My issue is twofold:
1) the most important -- use of the *| is confusing and reversed from normal path layout
2) certain things appear not possible with current, such as different patterns for folders and files.

Yes, admitedly one can achieve a "all files -or- A* folders" with current but knowing/remembering that it's done by *|A* isn't logical to me, because I think of path seq and thats' not it....folders come first, then files..