Exclude specific line #316
Comments
|
Just hasn't been implemented left. Different approaches
Considerations for inline directives
|
|
How about an ignore system the way tools like stylelint implements it:
Sometimes there is an requirement of having "wrong" code and adding all these items (see #544) to the ignore list might lead to missed fixes down the road. |
|
Following up on #613 (comment), my main use case is wanting to allow a specific word as allowed, while not preventing it from being flagged elsewhere. Inline comment would be the most focused. From an implementation perspective, different comment syntax between languages shouldn't really matter if you just look for some unique string exists in a given line. That way each lang can start the comment with whatever syntax they use. Granted this would be harder if parsing is done token by token, not line by line however. The start/end directive, or even as mentioned later a "ignore next line" could also work well, allowing the parser to be aware of what is coming up, versus trying to act upon something it already parsed. Scoping This is definitely something I'd love to see. Feels so hacky globally ignoring a misspelling when it only matters in a handful of contexts. E.g. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer |
|
I just started looking at using Line-specific ignores are the main feature I'd look for that isn't present already. For me this mainly applies to tests, which can include intentional errors. I agree with others that excluding an entire file (or splitting content out into another file), or an entire word, is rather a large hammer right now. I found this is also missing in |
|
Huh, seeing the discussion about using cspell's syntax is interesting. I like the idea of a cross-tool syntax, much like burntsushi helped create a cross-search tool ignore file. I'm still not a fan of supporting different comment styles. If anything, I'd prefer a common shibboleth that works independent of comment styles. |
Typos primarily works off of identifiers and words. We have built-in support to detect constructs that span identifiers that should not be spell checked, like UUIDs, emails, domains, etc. This opens it up for for user-defined identifier-spanning constructs using regexes via `extend-ignore-re`. This works differently than any of the previous ways of ignoring thing because the regexes require extra parse passes. Under the assumption that (1) actual typos are rare and (2) number of files relying on `extend-ignore-re` are rare, we only do these extra parse passes when a typo is found, causing almost no performance hit in the expected case. While this could be used for more generic types of ignores, it isn't the most maintainable because it is separate from the source files in question. Ideally, we'd implement document settings / directives for these cases (crate-ci#316).
|
FYI #695 provides a new workaround for false positives |
Typos primarily works off of identifiers and words. We have built-in support to detect constructs that span identifiers that should not be spell checked, like UUIDs, emails, domains, etc. This opens it up for for user-defined identifier-spanning constructs using regexes via `extend-ignore-re`. This works differently than any of the previous ways of ignoring thing because the regexes require extra parse passes. Under the assumption that (1) actual typos are rare and (2) number of files relying on `extend-ignore-re` are rare, we only do these extra parse passes when a typo is found, causing almost no performance hit in the expected case. While this could be used for more generic types of ignores, it isn't the most maintainable because it is separate from the source files in question. Ideally, we'd implement document settings / directives for these cases (crate-ci#316).
|
I believe that using inline exclusion is not a workable approach for a rather simple reason: it would be ineffective with file types that do not support comments, such as I think we need some kind of It's true that maintaining such a list will be cumbersome. However, to mitigate this problem, we could consider introducing a command-line option like I agree that inline comments have high appeal, but unfortunately they may not be universally applicable (although they could certainly complement the proposed approach). |
|
An "ignore all" mode sounds intriguing. I hesitate slightly because external excludes seems like a path of last resort and making it easy will likely incentivize people to not improve things, either within typos or in their repos. I think in normal modes we should warn if we check a file and the ignore is invalid (not an error in case its reasonable for two people to run different If we can, the syntax for this should be easy for |
I don't think it worth sacrificing the feature just because some file types don't have comments. Supporting inline exclusion would work and be helpful for many other file types. I could see supporting something like an external list in addition to inline exclusions for those kinds of files. But I don't really want to have to deal with it when 99% of files I use support comments. |
|
To be clear, I do not see them as mutually exclusive but that we'd benefit from both |
Typos primarily works off of identifiers and words. We have built-in support to detect constructs that span identifiers that should not be spell checked, like UUIDs, emails, domains, etc. This opens it up for for user-defined identifier-spanning constructs using regexes via `extend-ignore-re`. This works differently than any of the previous ways of ignoring thing because the regexes require extra parse passes. Under the assumption that (1) actual typos are rare and (2) number of files relying on `extend-ignore-re` are rare, we only do these extra parse passes when a typo is found, causing almost no performance hit in the expected case. While this could be used for more generic types of ignores, it isn't the most maintainable because it is separate from the source files in question. Ideally, we'd implement document settings / directives for these cases (crate-ci#316).
|
@epage it's a can of worms, but with tree-sitter you can run language specific parsers on filetypes and see what's actually a comment and what isn't. This could also be used for spicy options like
https://tree-sitter.github.io/tree-sitter/playground Have a look at the playground, it's amazing tech. Though it'd have to be a feature flag, tree-sitter is more correct than fast 😄 |
|
I am also always put off from tree sitter in dealing with all of the individual plugins and allowing people to extend a program with more. |
|
We are also looking for this kind of feature on our side, currently, we add exceptions such as |
|
Forgot to mention it in this issue but Some suggested regexes (including line ignore and block ignore) can be found at https://github.com/crate-ci/typos/blob/master/docs/reference.md#config-fields |
Hi!
I'm wondering why there is no directive that can be used to ignore a specific line? I have some files that have intentional typos in them that should be ignored, while the rest of the file should still be checked!
I'm thinking of a solution like
clang-formats:Did I not find that feature or has it been left out intentionally?
greetings!
The text was updated successfully, but these errors were encountered: