Feature request #1494: Don't show dotfiles unless query contains a dot

.gitignore
.cpan/...

stuff/.gitignore

sgi

s.gi

Comments

1. Greg Hurrell 2010-03-07T15:05:29Z

   Current behaviour:

   • Match class returns true for matches? with empty search string.
   • Matcher class uses alphabetical sorting in sorted_matches_for method when search string is empty.

   So, would need to:

   • Make Match class return false for matches? when any path component in the path begins with a dot, unless the search string contains a dot
   • Make Matcher class use alphabetical sorting in sorted_matches_for not only for empty search strings but also for search strings which contain only a dot

   And I think with those changes we'll basically have the desired behavior.

2. Greg Hurrell 2010-03-07T15:07:06Z

   Summary changed:

   • From: Don't show dotfiles unless query starts with a dot
   • To: Don't show dotfiles unless query contains a dot

3. Greg Hurrell 2010-03-07T15:13:17Z

   Note might be one tiny little gotcha with the "only if contains a dot" requirement; namely, that the offset corresponding to the dot must actually match up with a dot at the beginning of a path component.

   ie. given:

   foo/bar/.secret/baz

   And abbrev:

   fb.baz

   We want to match.

   But given:

   foo/bar/wincent.dev/.secret/baz
   foo/bar/wincent.dev/baz
   foo/bar/.secret/baz

   Is it really so clear which one we are expecting to match? Maybe the user does want the first result, but because the first dot appears in the middle of a component, they won't be shown the match if we impose that restriction on "must actually match up with a dot at the beginning of a path component". Alternatively, maybe they don't care about invisible files at all. How can we know this?

   The pitfall here is given paths like:

   .Trash/wanted.docs/other/map/baz
   web/wincent.dev/baz

   And a search string like:

   w.comb

   It's hard to know which one the user really wanted, and if they actually care to see hidden files at all.

   Will need to think more on this.

4. Greg Hurrell 2010-03-07T15:19:50Z

   To summarize:

   • if we require the dot to be at the start of the search string we lose the ability to search by specifying chars in the entire path

   eg. can't search for:

   foo/bar/xyz/.gitignore

   with:

   fbz.g

   • if we allow the dot anywhere then we might be pulling in a whole bunch of rubbish we're not interested in

   eg. thousands of files under:

   .cpan/...

   For an innocent query like:

   foo.c

5. Greg Hurrell 2010-03-07T15:34:57Z

   I guess in most working directories the number of dotfiles isn't high enough that pulling in too many dotfiles by accident is much of a problem.

   It only is a problem with pathological cases like the home directory with literally thousands of files inside dot directories (mine, for example, has about 12k paths that are either dot files or are an item inside a dot directory hierarchy).

   So I guess we have to optimize the design for the most common workflow.

6. Greg Hurrell 2010-03-07T16:59:37Z

   Two thoughts have occurred to me.

   One: even though this approach of displaying dot files whenever a period appears may end up with some "false positives", it's still better than what we have now (where we always show dotfiles).

   Two: there might actually be a fairly elegant algorithm for checking whether to display a dotfile or not, which I will describe below.

   Basically, in pseudo-code:

   # this is the Match class, when deciding whether or not
   # to classify something as a match
   if match contains a dot at the beginning of any path component
     (note that this conditional doesn't require a separate pass through the string,
      it can be done on the initial pass while trying to detect a match; we flag such
      strings for a separate pass through the string as described here)
     scan through each letter of query string
       if character is a dot
         if offset is zero
           this is a path starting with a dot: we have a match!
         else
           look up character just to left (offset - 1)
           if it is a path separator (/)
             this is a path component starting with a dot: we have a match!
           else
             this particular dot isn't enough to consider this a match
             but seeing as the match algorithm always picks the leftmost match
             there might actually be another qualifying dot up ahead before
             the next match... so:
             scan ahead up to but not including next matched offset
             if we see a dot before we hit the next offset
               and if that dot is right after a path separator
               then we have a match
           end
         end
       end
     end
   end

7. Greg Hurrell 2010-03-07T17:19:25Z

   Applying the algorithm to the examples cited so far in the thread:

   Path:

   • stuff/.gitignore (filtered)

   Queries:

   • sgi: no match (good)
   • s.gi: match (good)

   Paths:

   • foo/bar/.secret/baz (filtered)
   • foo/bar/wincent.dev/.secret/baz (filtered)
   • foo/bar/wincent.dev/baz
   • foo/bar/.secret/baz (filtered)

   Query:

   • fb.baz: finds paths 1 (good), 2 (good), 3 (good) and 4 (good)

   Paths:

   • .Trash/wanted.docs/other/map/baz (filtered)
   • web/wincent.dev/baz

   Query:

   • w.comb: finds path 2 (good) but not path 1 (good)

   Path:

   • foo/bar/xyz/.gitignore (filtered)

   Query:

   • fbz.g: finds path (good)

   So looks to be pretty good.

8. Greg Hurrell 2010-03-08T03:37:58Z

   Implemented. Will mark as closed.

9. Greg Hurrell 2010-03-08T03:38:03Z

   Status changed:

   • From: new
   • To: closed

Add a comment

Comments are now closed for this issue.