Skip commented_code_linter if actual parsed content was matched. #722
Conversation
AshesITR
changed the title
|
TIL parsed content includes COMMENT tokens :) |
Why not drop the |
|
I'm working on an XPath version, will push something later. |
|
NB we still need the regex to extract potential code from the comments |
| all_comments <- xml2::xml_text(all_comment_nodes) | ||
| code_candidates <- re_matches( | ||
| all_comments, | ||
| rex(some_of("#"), any_spaces, |
There was a problem hiding this comment.
this part isn't needed anymore right? ditto for anything in the capture?
There was a problem hiding this comment.
I think we need to anchor on the (first) # of the comment text, which will always be there in order to get the column_offset correct, but I'm not completely sure.
It depends on how the start and end locations of capture groups are returned by rex. If they are relative to the input string, we can probably prune the regex to only extract the code candidate to be analyzed. Note that we will still need to somehow anchor it to just after the comment start token, or it will match the entire string including the # which would always return a parseable (comment-only) code.
The COMMENT token will contain the # character starting the comment, so the refactoring as is is more or less sure to deliver the same candidate code as before if no # is present in actual code. WDYT?
There was a problem hiding this comment.
Sure, agree it's safer not to try & rock the boat any more than necessary during a refactor.
fixes #451