Extending the list of "working path mode" markers.

[tplunket]

When g:ag_working_path_mode is 'r', the working directory is changed to a location which is divined to be the "project root." At present, that means that that a function is called to search up the hierarchy from the current working directory until one of a list of items is found. That hunt is implemented something like this:

" l:searchdir is the current directory we're examining and it ends with a '/'
for l:marker in ['.rootdir', '.git', '.hg', '.svn', 'bzr', '_darcs', 'build.xml']
  let l:item = l:searchdir . l:marker
  if filereadable(l:item) || isdirectory(l:item)
    return l:searchdir
  endif
endfor

My needs have evolved over time but generally these days I get away with adding 'tags' to the list would suffice. Is this common enough that it should just be added to the default?

My local changes are two-fold. One thing I did was make the list a global configuration item (named g:ag_working_path_root_markers). The other thing that I did was make the function that locates the project root a configuration variable as well; unfortunately it seems that function references need to have a leading capital letter while non-function variables need to begin with a lower case, so I couldn't fold them together. I use this replacement function for a job I had where the project root could be queried directly by a function so it made sense just to put that into place.

Should I put either or both of these up for review, or should I just add 'tags' to the list and be done with it?

[tplunket]

It seems that I've submitted the "use a different function" method as a PR already, #127. It may not be absolutely necessary (as for my workflow now 'tags' is enough to look for) but the work is done...

[Numkil]

That's a nice idea @tplunket I'm really all for creating a parameter g:ag_working_path_root_markers. Overriding the entire function seems a bit overkill for me though but still some people might want to use it. +1

[tplunket]

@Numkil any thoughts for or against me adding 'tags' (and I suppose emacs-friendly 'TAGS') to the list default? I'll create a PR for this a little later.

[Numkil]

I have never seen 'tags' used as a project marker before but I guess expanding the default list should not be anything to worry about. I still would like to see the list of markers exposed as a parameter though :)

[tplunket]

See :help tags in the Vim documentation. It will tend to be at the root of projects where the user needs to do a lot of navigating to function definitions but doesn't necessarily know where those functions are defined. The file is generated by a program like ctags.

[Numkil]

Fits the bill perfectly then. Exactly the reason I made this function. :)

[tplunket]

See PR #143 and feel free to give feedback on it. I did it against the rking/master so that branch doesn't have all of the Windows fixes in it, I keep hoping that that other PR will get accepted one day...