Bug #1542: wildignore settings not working

set wildignore+=vendor/rails/**

Comments

1. Greg Hurrell 2010-04-20T15:36:44Z

   Right, thanks for the report.

   I hadn't seen 'wildignore' used in this way before (ie. with upper pathname components and the recursive ** notation) so I'll have to look into it.

   Right now Command-T is just looking at each item in 'wildignore' and seeing if it matches against the current item (file or directory) being scanned, and if it does, it skips it. So as it currently stands there is no setting of 'wildignore' which will give you exactly what you want, except for perhaps :set wildignore+=rails, which could potentially hide more than you're actually wanting to.

   My only concern here is that both uses of ** that I can find in the manual (for expand() and globpath()) use it in the form "**/somefile", so I will have to experiment with it to see if it can be made to work the way you're wanting it to.

2. Greg Hurrell 2010-04-20T15:40:19Z

   Just did a test and it doesn't seem to expand the way you think it does...

   :echo glob('**/README')

   In a Rails project echoes:

   README
   vendor/plugins/rails_upgrade/README

   But:

   :echo glob('vendor/rails/**')

   Echoes nothing at all.

3. Greg Hurrell 2010-04-20T15:42:48Z

   Actually, scratch that... It seems to have some kind of internal depth limit, because it is not returning all the README files which I know to be in the vendor/rails hierarchy. So I'll have to try it on a smaller directory hierarchy to see if the something/** notation works or not.

4. Greg Hurrell 2010-04-20T15:44:32Z

   Ok, tested on a smaller hierarchy and it does seem to work.

5. Greg Hurrell 2010-04-21T13:18:19Z

   Ok, just thinking out loud here on what the semantics of this should be if globs like **/foo, foo/**, or even foo/bar are to be supported.

   The typical use case (99% of the time) for 'wildignore' is to ignore stuff like object files (*.o), backup and temporary files (*.bak, *.tmp, *~), and things like SCM metadata directories (eg. .git etc). So here we're always talking about matching against a filename, no matter where the file actually is in the directory hierarchy.

   If we start talking about something like foo/bar, should those same semantics — that is, match against the pattern regardless of where it is in the hierarchy — still apply? ie. should all the following be filtered?

   • foo/bar
   • foo/bar/baz
   • abc/foo/bar
   • abc/foo/bar/baz

   Or should it obey different semantics and consider itself relative to the project root only? ie. only the first two in the list above would be filtered, and the other two would not.

   Likewise for a pattern like foo/**, should it match foo anywhere in the hierarchy, or only at the root?

   If the former, then the pattern may as well just be foo because it will have the same effect.

   For a pattern like **/foo, it's the same deal really. By definition the ** will make this apply universally, regardless of where foo might be in the hierarchy. But once again, if that's really all you're wanting to filter then foo would be all you need anyway.

   Going back to the example posted by the ticket owner, vendor/rails/**, the presence of ** here kind of implies that the user wants the pattern to be anchored to the project root, at least according to my interpretation. **/vendor/rails would be an explicit way of specifying that the pattern should not be anchored.

   I'm guessing that the most intuitive/coherent way to proceed then is probably going to be the following:

   • foo/** or foo/bar/** etc express a desire for anchored pattern matching (anchored at project root)
   • **/foo or **/foo/bar etc explicitly express a desire for unanchored pattern matching
   • foo and even foo/bar should adopt the default (ie. unanchored) behavior

   This means that patterns like **/foo and **/foo/bar could always be written more concisely as foo and foo/bar respectively.

   Algorithmically, I guess it'll just be a case of splitting patterns on the path separator (/), and starting matching from right to left. That is, if rightmost component matches, we check the parent component against the component to the left, and the grandparent against the left of the left and so on.

   ** as a leftmost component is effectively ignored. ** as a rightmost component triggers the anchored-match special case, which we can actually check for as a first step so as to potentially short-circuit the normal procedure. (For that case would probably do a left-to-right check instead.)

   Finally would just need to make sure we correctly handle (bizarre?) stuff like:

   • **/foo/bar/** (as leading ** is the default behavior, this is effectively equivalent to foo/bar/**)
   • **/a/**/b/**/c (pathological, but to be properly robust we have no choice but to handle it I guess)

   As well as ensure that other glob patterns like the following continue to work:

   • *.o

   As well as when combined with other components:

   • **/foo/*.o
   • foo/*.o etc

   This will be a little fiddly to implement, so I am going to leave this ticket open for a while to see if anybody has any feedback to add.

6. Michael Henry 2010-04-28T15:19:42Z

   I'd been looking for simpler behavior than requested in this posting, and I thought I'd need to submit a feature request; But it turns out my test procedure was wrong, and CommandT already handles my scenario.

   I want to ignore content in any directory named "build". I'd tried ":set wildignore += build", but it didn't seem to have any effect. The problem was that I hadn't thought to do ":CommandTFlush" before re-trying ":CommandT", so I was seeing the cached contents of my build directory.

   So it turns out that CommandT already supports my more limited use case :-) I thought I'd mention it here in case a documentation update might be helpful to other users that might make my mistake.

   Perhaps a sentence like this near "command-t-wildignore" would be useful:

   Changes to the 'wildignore' setting will not apply to cached directory contents; therefore, after modifying 'wildignore' it is recommended to flush the cache using :CommandTFlush.

7. Greg Hurrell 2010-04-28T18:03:03Z

   Changes to the 'wildignore' setting will not apply to cached directory contents; therefore, after modifying 'wildignore' it is recommended to flush the cache using :CommandTFlush.

   Seeing as pretty much the same comment applies to all settings**, I think I'll add such a comment at the very beginning of the "OPTIONS" section of the docs.

   (** about the only ones which get picked up automatically are changes to the key mappings, seeing as they are set-up fresh for the buffer each time it is shown)

8. Greg Hurrell 2010-05-11T10:45:05Z

   I'm going to close this ticket as there has been a proposed patch submitted (see ticket #1555) which adds support for pretty much anything you might want to add to 'wildignore' by using VIM's expand() function to check each path (seeing as expand() will automatically omit any path which matches the 'wildignore' patterns).

9. Greg Hurrell 2010-05-11T10:45:11Z

   Status changed:

   • From: new
   • To: closed

Add a comment

Comments are now closed for this issue.