Why?
====
Frequency of a tool's usage is determined by how easy it is to use the
tool. By having to pipe in ctags files all the time, and not provide any
guidance to the user, this program is merely a toy, since it's hard to
get right, and harder to explore.
This modifies the default behavior to look for a ctags file in a few
common locations, and lets the user choose a custom location if she so
chooses.
Resolves#35
Why?
====
Handling low likelihood configuration was previously a huge pain,
because the syntax in Haskell was fairly terse. This introduces a yaml
format internally that ships with the app covering basic cases for
Rails, Phoenix, and Haskell. I could imagine getting baselines in here
for other languages and frameworks (especially ones I've used and am
comfortable with) as a baseline.
This also paves the way for searching for user-provided additions and
loading those configurations in addition to what we have here.
Why?
====
This library converts lots of strings to positive integers
(specifically, when it's parsing output from search results). Because
these are always positive integers, we can make more assumptions about
the data and how to parse the values.
Corresponding benchmark: https://gist.github.com/joshuaclayton/767c507edf09215d08cdd79c93a5f383
Why?
====
Calculating the SHA of the entire tree can be expensive; this shifts
reading from/writing to the cache to be configured via a switch in the
CLI.
In the future, it might make sense to store metadata about the repo,
including historical time to calculate both the SHA and non-cached
versions, to compare and choose which one to do intelligently.
At some point, this also needs to md5 the tags list itself and factor
that in (since if the tagging algorithm changes, and new tokens get
uncovered, it'd invalidate the cache)
Why?
====
ag supports using regular expressions for searches; however, the -Q
flag, which was previously always used, resulted in literal search
results.
By searching literal matches, it would potentially return too many
results. For example, with a `me` method in a controller, it'd match
words like `awesome` or `method`.
This introduces a check where, if the token being searched is only
composed of word characters (`[A-Za-z0-9_]`), it'll switch over to use
regular expressions with ag and surround the token with non-word matches
on either end. The goal here is to reduce false-positives in matches.
Why?
====
Grouping results can be helpful to view information differently, e.g. to
see highest-offending files or to remove grouping entirely.
This introduces a flag to allow overriding the default group (two levels
of directory)
Why?
====
Searching hundreds or thousands of tokens with ag can be slow; this
introduces parallel processing of search so results are returned more
quickly.
Why?
====
Parsing lines of results was somewhat unreliable, and terms with odd
characters were causing problems. This:
* extracts parsing into an Unused.Parser.Internal module for ease of
testing
* fixes cases where certain tokens weren't matching
This commit also moves `eol` into the `parseTermMatch` parser, which should be
safe since `parseTermMatches` is the only place that `parseTermMatch` is used.
Why?
====
By default, people want to see an actionable, comprehensive list without
having to pass any flags into the program.
Previously, to see everything with high likelihood you'd need to provide
`-a --likelihood high`. This commit changes the program so that's the default.
It also introduces a `--all-likelihoods` flag (shorthand is `-a`) to see
everything, so if you want to opt into see it, you can. Finally, this
changes `-a` (to see everything) to `-s` (to see only single
occurrences, which was the previous default).
