Ensure alignment of issue URL line is correct even
when the TODO line had any number of tab
characters prior to the issue title
Addresses remaining sub-issues of and
closes GitHub issue #245
Fix a regression that was accidentally introduced
with v5.1.2 which could cause an issue URL to not
be successfully added to the source file when
dealing with a CRLF (Windows-style line endings)
file on Linux.
Partially addresses GitHub issue #245
Provides a test for and the solution to GitHub
issue #242. Namely, an identifier which contains
regex characters (e.g. "[TODO]") is properly
handled by having the parser look for literal
"[" and "]" characters rather than treating those
characters as part of a regex pattern. The word
boundary regex pattern '\b' does NOT properly
handle this, so a slightly different pattern is
used to identify the boundary.
If TODO comment is a suffix to a line of
(executable) source, don't repeat the source
content when inserting the issue URL. But be sure
to still keep the same alignment.
Closes#229
Some parts of the code were using case-insensitive
matches when searching for an identifier (i.e.
TODO and todo would both be acceptable) whereas
other parts of the code would search for a strict
case-sensitive match (only TODO, not todo). This
inconsistency led to many issues, among them
- #216
- #224
- #225
Further, the identifier match wasn't being done
using word breaks, meaning an identifier of "FIX"
would match (case-insensitively) with "suffix" or
"prefix" if those words happened to appear in a
comment. (See #234).
Issue #230 was also preventing issue labels from
being applied properly if the identifier case
did not match exactly the canonical version. i.e.
"todo" would generate an issue, but the associated
labels wouldn't be applied because the exact
identifier used wasn't "TODO".
This commit resolves all of these issues.
Split main.py into modules to (mostly) isolate the
GitHub-specific code from the general TODO
detection and program logic.
This is both for readability/maintainability and
to prepare for potentially supporting other
version control systems (e.g. GitLab, BitBucket).
