disable lints for some lines and re-enable afterwards or generally reconfigure during check-time

[NobbZ]

I have some comments with a link in it and the linter complains about their length.

I can not break the links into multiple lines, as that would destroy them and make dealing with them unnecessarily hard.

On the other hand side, I do not want to disable fill-column checks for the affected files.

Instead I'd like to disable the lint for a section of the file, like this:

;; (elisp-lint-disable 'fill-column)
;; Lets assume this line is to long, but we accept it
;; (elisp-lint-enable 'fill-column)

Maybe we can even override and reconstruct settings?

;; (elisp-lint-push 'fill-column 120)
;; For this line the fill column is 120
;; (elisp-lint-pop 'fill-column)
;; fill coumn is back to its original value now

[gonewest818]

I'm not sure I can guarantee a case where a variable like fill-column has a value that changes for certain ranges of lines. That would seem to require modifying the internals of the individual checks, and I'd prefer to stay away from that.

Rather, what I think I can support is disabling and enabling checks over certain line number ranges:

;; elisp-lint-disable: fill-column

    ;; For these lines, don't generate fill-column warnings regardless of the line length

    ;; elisp-lint-disable: checkdoc
        ;; Nesting these ranges seems feasible also. 
    ;; elisp-lint-enable: checkdoc

;; elisp-lint-enable: fill-column

Would need to implement a preprocessing scan to walk the file and read these specially formatted comments, and build the list of line number ranges. After the checkers run, we just filter the resulting list and drop warnings that occur in those disabled regions.

I just opened a similar ticket specifically for the package summary line at the top of a file. That's one I can easily special-case because the fill-column test is rather simple (and where I can't use a "pragma" to "wrap" the lines in question, because the package summary is expected to be precisely the first line in the file).

[wpcarro]

Something like ;; elisp-lint-disable-next-line: fill-column might be useful. For my particular use-case, I pretty much need to ignore URLs that I embed in comments that run over 80 characters.

[noctuid]

This would be amazing. I've wanted to set up automatic linting that will automatically fail a CI build for a long time, but it's just not possible for elisp because of all the false positives.

[gonewest818]

What would you all say to a feature that disables fill-column on comment lines only?

A different kind of special case but seems to be the most common exception.

[noctuid]

Package-lint is the real issue for me. I have dozens of invalid warnings in some of my packages. It makes package-lint nearly useless because it's too time-consuming to go through so many warnings every time I make a change to see if there's something new. Checkdoc also has some annoying cases, but you can often work around them. Eventually having some sort of generic mechanism for all validators would be great.

Some linters for other languages will ignore long lines if they contain a url. Not sure how difficult a more specific check like that would be to implement, but an option to just disable fill-column for comment lines would still be useful.

[TLATER]

Forgot to check for other PRs before firing that off, but I think that #29 basically covers 99% of the cases in which I'd need to turn off the fill-column part of the linter. I don't currently have other use cases.

A feature to bulk-disable fill-column checks specifically on comments seems like an anti-feature to me. fill-column is most relevant for comments in general, since that's bulk text people actually have to read, which is when reading comfort and disabilities become especially significant. It's only a problem when we try to embed text into comments that isn't intended to be read, which elisp-lint already special cases for nicely.

Just needs that small enhancement for the far too common use case of dumping links to the root cause of some odd edge case I'm working around ;)