Scripts on PFA

[jacky]

Code: Select all

  +++ Scripting and Portable File Associations (PFA): Now you can state 
      a one-line script as "application" in the definition of a PFA! 

You know, that sounds really cool, but I have to say it would be even better if there was a way to define a pattern instead of an extension, much like what we can do in Color Filters.

(Even better would be, for both PFA and Color Filters, another extra way to have such pattern be treated against the full path and not just the filename, so I could have specifics for say D:\Music\*.mp3 different than the regular *.mp3, things define for D:\Project\* or ?:\recylced\* or many more!)

[admin]

Code: Select all

  +++ Scripting and Portable File Associations (PFA): Now you can state 
      a one-line script as "application" in the definition of a PFA! 

You know, that sounds really cool, but I have to say it would be even better if there was a way to define a pattern instead of an extension, much like what we can do in Color Filters.

(Even better would be, for both PFA and Color Filters, another extra way to have such pattern be treated against the full path and not just the filename, so I could have specifics for say D:\Music\*.mp3 different than the regular *.mp3, things define for D:\Project\* or ?:\recylced\* or many more!)

Yep, I have thought of that immediately as well.

What about:
- if the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- elseif the pattern contains the character ":" then it's treated against the full path. Should work...
- else it's treated against the file name.

[jacky]

What about:
- if the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- elseif the pattern contains the character ":" then it's treated against the full path. Should work...
- else it's treated against the file name.

hmm.. yeah, that sounds right. I just think I would switch the two first :
- if the pattern contains the character ":" then it's treated against the full path
- elseif the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- else (no ":" but wildchars) it's treated against the file name.

Just to allow to use a full path/name without wildchars.

The only question is, should relative syntax be supported here as well. Because it might make sense to use it, and then "?:" syntax would work (since there's a ":") and we could use "*:" to specify any drive (not the one from where XY is running)

But the problem is with the other syntax, relative paths (eg: "..\Folder" or "Scripts\*.xys")

So maybe it shouldn't be based on ":" but on ""

That would give us:
- if the pattern contains the character "" then it's treated against the full path (relative syntax supported)
- elseif the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- else (no "" but wildchars) it's treated against the file name.

[admin]

What about:
- if the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- elseif the pattern contains the character ":" then it's treated against the full path. Should work...
- else it's treated against the file name.

hmm.. yeah, that sounds right. I just think I would switch the two first :
- if the pattern contains the character ":" then it's treated against the full path
- elseif the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- else (no ":" but wildchars) it's treated against the file name.

Just to allow to use a full path/name without wildchars.

The only question is, should relative syntax be supported here as well. Because it might make sense to use it, and then "?:" syntax would work (since there's a ":") and we could use "*:" to specify any drive (not the one from where XY is running)

But the problem is with the other syntax, relative paths (eg: "..\Folder" or "Scripts\*.xys")

So maybe it shouldn't be based on ":" but on ""

That would give us:
- if the pattern contains the character "" then it's treated against the full path (relative syntax supported)
- elseif the pattern contains no wildcards: it's treated against the extension (ensuring backward compatibility)
- else (no "" but wildchars) it's treated against the file name.

Couldn't make more sense. Great!

[Pagat]

Code: Select all

+++ Portable File Associations (PFA): Before, you could only state 
      lists of extensions to match the opened file against. Now you can 
      state whole file names or even full, relative, or portable paths; 
      patterns containing wildcards are allowed.

Since jacky already mentioned color filters:
I do have situations where i only want to highlight some files in specific directories. Any chance that this system will be implemented for color filters too?

[jacky]

Since jacky already mentioned color filters:
I do have situations where i only want to highlight some files in specific directories. Any chance that this system will be implemented for color filters too?

Yeah, that would be realy cool. For color filters and since they're not extension-based, I believe all should be added is: if "" then treated against full path (w/relative syntax), otherwise against filename only.
Could be useful for color filters-only situation, as well as to relate how PFA will behave as well...

[admin]

Code: Select all

+++ Portable File Associations (PFA): Before, you could only state 
      lists of extensions to match the opened file against. Now you can 
      state whole file names or even full, relative, or portable paths; 
      patterns containing wildcards are allowed.

Since jacky already mentioned color filters:
I do have situations where i only want to highlight some files in specific directories. Any chance that this system will be implemented for color filters too?

Yo, why not. Done.

[Pagat]

Great! Thanks.