Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for linters with non-zero exit codes and read from stderr #109

Closed
gontzalm opened this issue Oct 4, 2023 · 4 comments
Closed

Comments

@gontzalm
Copy link

gontzalm commented Oct 4, 2023

First of all, thanks for the awesome plugin.

I am trying to add the markdownlint-cli linter to guard.nvim. I encountered two issues:

  • Currently guard.nvim does not support non-zero exit codes and markdownlint uses other exit codes.
  • markdownlint outputs linter errors (diagnostics) to stderr, and guard.nvim discards this stream.
  • markdownlint does not have an error severity, so the attributes.severity key cannot be specified in the lint.from_json function.

Are you planning to support linters with this behaviour? I attempted to fix this adding a valid_error_codes tool option and other changes in the commit gontzalm@ea99961.

Now the linter is working with the options

local ft = require("guard.filetype")
local lint = require("guard.lint")

ft("markdown"):lint({
    cmd = "markdownlint",
    args = { "--json" },
    fname = true,
    valid_exit_codes = { 0, 1 },
    source = "markdownlint",
    parse = lint.from_json({
        source = "markdownlint",
        attributes = {
            lnum = "lineNumber",
            col = "lineNumber",
            message = "ruleDescription",
            code = function(d) return d["ruleNames"][1] end,
            severity = function(_) return "warning" end,
        }
    })
})

require('guard').setup()

image

@xiaoshihou514
Copy link
Collaborator

xiaoshihou514 commented Oct 5, 2023

Thanks for the attention! I am aware of this (#68). What I planned was separating some of the do_fmt and do_lint function into an api module. So ppl could write their own formatting/linting process when their tool it's behaving out of ordinary.
I feel this approach makes guard core less cramped (not having to parse an ever-growing tool specification) and enables users to implement stuff like #76 and #86.

I am (hopefully) going to work on this after the autocmd pr gets merged.

@xiaoshihou514
Copy link
Collaborator

xiaoshihou514 commented Oct 5, 2023

Oh and from_json and from_regex is meant to be a template for the majority of tools so it's natural that it won't fit for some.

@imbolc
Copy link

imbolc commented Jun 12, 2024

Just found that Asqlfluff format too sometimes returns formatted text to stdout with a non-zero error code if there's still issues left.

@xiaoshihou514
Copy link
Collaborator

xiaoshihou514 commented Jun 12, 2024

Just found that Asqlfluff format too sometimes returns formatted text to stdout with a non-zero error code if there's still issues left.

Yep, #150 should solve all of these :)
Though changes in guard-collection would be needed. I will also write some tutorials in ADVANCED.md

@xiaoshihou514 xiaoshihou514 mentioned this issue Jun 12, 2024
9 tasks
xiaoshihou514 added a commit that referenced this issue Jul 21, 2024
closes #68 #86 #123 #109 #76 #141 #111
## changes
- [x] remove uv.spawn wrapper in favour of vim.system
- [x] `do_lint` now respects *all* config fields
- [x] linter can now use lnum_end and col_end
- [x] added step by step tutorial for advanced usage
- [x] remove all version checking code, only supports 0.10+ from now on
- [x] apply exepath fix for windows

## internal changes
- [x] events now contains truly all autocmd related functions
- [x] utils now contains execution checking functions
- [x] use custom simpler table copy
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants