There is no reason why '.' should be added only to the Unix branch and
not to the Windows one as well.
However, I disagree that looking for ./.ackrc is a desirable feature,
at least not the way it is currently implemented. I would consider it
a bug if ack worked differently depending on my current working directory,
especially if I specify an absolute path name for the search. And
I certainly don't want to `cd` into the directory first before being
able to search it with locally modified rules.
I _could_ see some value in a directory-specific .ackrc file if it would
only be applied to files found in that particular directory. That way
you could add additional extensions on a per-directory basis. This will
require a different implementation though, and I'm not convinced that it
is worth the effort.
Cheers,
-Jan
since we don't integrate with exactly one IDE we don't know from
'current project' so CWD is the only workable proxy available.
I could argue that if there is no .ackrc in . that search should go up
.. chain before going to $HOME and $ACKROOT as if CWD is a subdir of a
project, behavior should be the same.
> especially if I specify an absolute path name for the search. And
an absolute path has some extra information, and using an .ackrc there
would make sense, but the language(s) of interest may still be
indicated by ./.ackrc or personal preferences / prejudices still
belong in ~/.ackrc not in shared areas. We probably don't want to
merge three sets of options as if it was CSS , but there's an argument
for it. A user with firm prejudices but needs local tweaks can copy
~/.ackrc ./.ackrc and tweak as needed.