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).
Why?
====
A simple calculation ("yes, this should be removed" or "no, this is
probably fine") is frankly not enough information for someone evaluating
their codebase to understand why we made the decision.
This introduces a removal reason, so a user understands why we ranked it
the way we did, and adds additional logic around a method and its tests
to determine if a method exists and is only being used in the tests (if
so, it should probably be deleted).
This is done with an Occurrances record, which is created for total
files, test code, and non-test code. The test code logic is somewhat
naive but works in most cases. It doesn't ensure a particular directory,
in the case that tests live alongside source code (e.g. Go), and
captures RSpec cases as well.
Why?
====
Formatting each column requires context on the column, as well as
information on alignment. This extracts the column formatting logic to a
specific formatter.
ColumnFormatter is coupled to the order of columns/data displayed to the
user.
Why?
====
Unused hides the cursor and potentially does other things to the window that
may leave it in an odd state. This introduces a hook to run any state
cleanup, including re-enabling the cursor, when a user sends a SIGINT to
the program.
