Using folder names in Buffers/Project/Workspace file load view

[Brandon]

I use this popup view extensively (as I'm sure many do) to locate and switch to project/workspace files.  In my projects I deal with a large offline data sets (to simulate online functionality) consisting of over 1500 JSON files.   In my situation as a web app dev, the offline data is organized by folder, and the target data files in all folders have the same name "data.json".

Currently if I need to load a particular data file, like "productinfo", I have to just scroll through the whole list to find it.

I am looking for either a secret config flag or a mod to allow me to type a leading "/" to specify a folder match instead of filename?

For example, I type "prod" and I get hits for filenames with 'prod' in them. 

However, I type "/prod" and I get the following hits from the path:

/root/ver1/extensions/product/productinfo/data.json
/root/ver1/extensions/product/productconfig/data.json
etc

This would *vastly* improve file handling efficiency.

[Clark]

"prod*\" seems to work (or "\prod*\" which is more precise).

If you type "data", that will match the file part, and you can pick the one from the right path. Also "info\data" does some potentially useful matching for this case.

All the options for this file matching seem to be for how the file name part is matched and not the path.

[Brandon]

Wow I can't believe all this time I could have been using this.  While I am happy that this works, it seems a bit unintuitive.

I can confirm that "prod\" works to match the path, but I don't understand why.   

It seems that the path-matching trick requires the slash at the end, but wildcards are needed if using more than one level of path.

So "prod\" is equivalent to "prod*\" (as long as its the last path before filename), but if you add one or more path levels, you must use * wildcard after the path name in each, such as:

"conf*\rel*\prod\data" 
because
"conf\rel\prod\data" will not work.

But again, oddly the wildcard is not needed in the level just before the filename.

[Clark]

I can confirm that "prod\" works to match the path, but I don't understand why.   

That one does seem confusing. The code roughly does a contains match for the path part. If you type path-part\name-part, the path part gets converted to **\path-part** (this is verify simplified-- there are special cases). More conversions are done on the name-part depending on your options. Ultimately it results in an ant-like file pattern.

[Graeme]

Wow, awesome.  I nearly started writing some code to see if I could do the folder filtering.  Glad I didn't.

I wonder how the filtering capability could be advertised a bit better.  How about having some "greyed out" kind of text in the filter edit box that appears whenever the filter edit box is empty.
e.g.  Press F1 for help on filtering.

Below is from the help file.  It should mention the directory filtering stuff.  Also it seems to be missing some detail on all the prefix matching options.

The Filter text box can be used to display matching file names. Files are removed from the list that do not contain the specified text. For example, if you type "ml," the Files list is filtered to only show file names that contain the letters "ml," as they appear in that order, anywhere in the file name.

To allow Fast Prefix Matching inside the Filter text box, right-click inside the Files list area and select Prefix match. When prefix matching is on, matching starts at the beginning of the word. For example, if you type "d," the Files list is filtered to only show file names that begin with the letter "d."

When the focus is not in the Filter text box, you can incrementally search the list of file names by typing the first few characters of the name. If you pause for a few seconds, the search is reset, and you can search for a different file name just by typing the first few characters again. You do not need to press Backspace, or reselect the first item in the list. Regardless of which item is selected, incremental search starts at the top of the list. For example, if items are sorted in descending alphabetical order, the incremental search starts at the top of the list, which would be the file that would appear last, if sorted in ascending alphabetical order.

[Clark]

We will take a look at the help and update it. It should at least say it supports an ant-like filespec but more details would be helpful

[Clark]

Docs updated for Files tool window and Open tool window. New docs will be in SlickEdit 2017 beta 2.