Allow including and excluding files from the list using globbing pattern - p3

[ghost]

Sometimes users (or developers) may wish to hide certain files. It would be convenient to use a globbing pattern in such cases. For example, consider the following API:

  /**
   * Sets the list of file names to display. For example, a single call to
   * this method with values of ("**.pdf", "Portable Document Format (PDF)")
   * would display only a file listing of PDF files.
   *
   * @param glob        Pattern that allows matching file names to be listed.
   * @param description Human-readable description of the pattern.
   */
  void addIncludeFileFilter( String glob, String description );

  /**
   * Sets the list of file names to suppress. For example, a single call to
   * this method with values of (".*") would prevent listing files that begin
   * with a period.
   *
   * @param glob Pattern that allows matching file names to be suppressed.
   */
  void addExcludeFileFilter( String glob );

Multiple calls would be permitted, as well as mixing. Such as:

builder.addIncludeFileFilter( "**.md, **.Rmd, **.markdown", "Markdown Files" );
builder.addIncludeFileFilter( "*.ps, **.eps", "(Encapsulated) PostScript" );
builder.addExcludeFileFilter( ".*" ); // Don't show hidden files

This API is a bit simpler, IMO, than creating JWFileChooserFilterType instances. (It's syntactic sugar, really.)

Given that the user cannot select excluded files, it needs no description. See FileSystem.getPathMatcher for globbing details.

[io7m]

I need to think about this a bit. For uniformity, I'd like to keep the implementation itself based around filters, but we could use a more terse API to create them (similar to the above example) and to allow for one or more filters to be invisibly and always enabled.

[io7m]

I'd like to nail down the semantics of globbing filters. An isolated "include" glob is easy to understand, as is an isolated "exclude" glob. Combining arbitrary includes and excludes is somewhat less easy to understand, and there are many different ways to interpret the combinations.

I generally favour the semantics provided by sequential evaluation with explicit halts. The key thing to note is that the rules are evaluated in declaration order, and the difference here would be that the match patterns would be the glob syntax supported by FileSystem.getPathMatcher. Would this be acceptable if I put a pleasant API over it?

[ghost]

I see what you mean.

builder.addIncludeFileFilter( "**.{md,Rmd,markdown}", "Markdown Files" );
builder.addExcludeFileFilter( "*.*md" );

I'd expect that all .Rmd files would be listed, but no .cmd files. Call order is imperative, yes, and enforcing it is fine. Perhaps throw an exception? Haven't fully thought this through, but the following examples should probably throw:

// Don't permit exclude before include?
builder.addExcludeFileFilter( "*.*md" );
builder.addIncludeFileFilter( "**.{md,Rmd,markdown}", "Markdown Files" ); // throw?

// Don't permit include after exclude?
builder.addIncludeFileFilter( "**.{md,Rmd,markdown}", "Markdown Files" );
builder.addExcludeFileFilter( "*.*md" );
builder.addIncludeFileFilter( "**.{asc,text}", "Text Files" );  // throw?

Even evaluating in declaration order without exceptions is fine, if you think it'll work. My preference is to force the programmer to deal with potentially ambiguous outcomes.

[io7m]

You might want to take a look at the feature/globbing-19 branch. There's information in the README.md file now about how the API works, and various unit tests.

[io7m]

I've merged the globbing-19 branch. Additions/changes should be specified in new tickets.