Ignore multiple characters in ignoreNextTo
wickedest opened this issue · comments
We want to ensure that when Docker is written, it is "Docker". But we also have cases where we reference a command, e.g. a really contrived example with 4 textual instances of the word:
Wow, Docker is great, see [docker run](https://docker.com). Check your /docker folder, or run "docker".
Naively, an attempt to ignore "docker run": { yes: 'Docker', ignoreNextTo: 'run' } won't work because the negative lookahead is an immediate character before or after the text (it might be useful to clarify this in the doc):
(?<!\.|@[a-zA-Z0-9/-]*)\b(?<!run)(Docker)(?!run)\b(?!\.\w)
Naively, an attempt to compensate might include a regex whitespace to ignore { yes: 'Docker', ignoreNextTo: '\s+run' } , but that doesn't work because the string is escaped. Only an actual space ' run' will work, but that now creates a rule where the negative look behind is checking "runDocker", which is fine, but a little inefficient and not exactly what I wanted. But the same rule cannot be reused for the / and " characters. The ignoreNextTo works best with single characters.
Creating multiple rules just generates multiple issues because the same text is processed each time for each rule. A rather silly example is "adocker dockerb". "a" can be ignored in one rule and "b" in another, but the first rule will complain about "dockerb" and the second will complain about "adocker".
The problem I see here is that the rule needs to be powerful enough to handle all possible cases in a single rule, and it's not, and technical text can contain a lot of quotes and slashes.
One idea might be to allow ignoreNextTo to be an array, e.g.:
ignoreNextTo: [ '"', '\'', '/', '\s+run' ]
It's not perfect because it's making the regex more complex (and it's already very complex), and the negative lookbehind is still weird checking for "\s+rundocker". In this array case, would allow the text to be regex. It doesn't have to, but it's strange having to write ' run' and it gives more flexibility.
I'd be happy to make PR for this.
No comment (yet) on the feature suggestion, but for this particular case, I'm pretty sure that if you put your command in backticks, it will be ignored.
docker run will get flagged
But `docker run` will be ignored as a command.No comment (yet) on the feature suggestion, but for this particular case, I'm pretty sure that if you put your command in backticks, it will be ignored.
docker run will get flagged But `docker run` will be ignored as a command.
Yeah, I just checked and there's even a test case for it. Strings inside backticks are considered commands and are ignored by default so that we can enforce Node.js and Gatsby but allow node and gatsby in command examples. Does that meet your need?
In other words, can you do this?
Wow, Docker is great, see [`docker run`](https://docker.com). Check your `/docker` folder, or run `docker`.y, I could change the example so that the tool would pass, but this is only a contrived example to explain the limitations. There can be cases where these are not commands, or where it is not appropriate to backtick. E.g.
We know docker/kubernetes is great, but our stuff is docker-less, or email us at docker@anywhere.io
y, I could change the example so that the tool would pass, but this is only a contrived example to explain the limitations. There can be cases where these are not commands, or where it is not appropriate to backtick. E.g.
We know docker/kubernetes is great, but our stuff is docker-less, or email us at docker@anywhere.io
If it's a valid use case for you and since you're offering to implement and document, I'd be happy to review the PR. Thanks for caring about the project!
I'm doing some clean-up and this one seems dormant. If there's an intention to implement this, leave a comment or re-open. Thanks!