-
-
Notifications
You must be signed in to change notification settings - Fork 210
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
Linting of injected langauges #439
Comments
Relates a bit to #235 I'd first like to see if there's more interest in this, before considering it. |
It does appear there's a desire for this feature to be implemented. It currently has the highest number of votes. |
This would be awesome for languages like Nix where I often end up injecting Lua or shell scripts with unchecked '' ''; blocks. |
Throwing my hat in the ring here as well. Injected SQL is my use-case. I have almost a perfect setup with treesitter queries and conform. Linting is the only missing piece. |
Do you mind sharing? |
Sure!
I'm set up for SQL inside of Python, but you should be able to replicate with any language inside any other. |
I've been thinking for a while on how to implement "linting of injected languages" using the existing code-base as-is, and (in theory anyway) it's not too difficult, I would just like to bring it up for a discussing before actually trying to implement it
conform.nvim has the same feature, but for formatting, and we can just re-use the core logic here (getting the injected languages via treesitter). I see it sort of like this:
ft
toinjected.language
injected.content
(without additional new lines, see below)nvim_buf_call(scatch_bufnr, M.lint())
on the scratch-bufferscratch_bufnr
(if LSP's are setup for the target language, these will also be picked up - feature?)vim.diagnostics.set()
the diagnostics in the main bufferI know of otter.nvim which does something similar, but for a limited set of languages, and only includes LSP features (which I'm not interested in). Otter.nvim creates a hidden buffer, but using newlines as offset, which I personally do not like, because some linters requires the first line to be a shebang (see shellcheck as an example), which is impossible to satisfy using the newline-approach
Instead, I'd suggest making a new buffer without newlines, but instead bump the lnum of the diagnostic itself afterwards, so it matches in the main buffer (i.e. if the injected block starts a line 5 in the main buffer, bump the lnum of the diagnostic by 4 (offset - 1). This makes the shellcheck example possible to "fix"
Since nvim-lint's
cmd
-field can only return a path to an external command (or a function that returns said command), above requires a new field, which can take a pure-lua functionconform.nvim
hascommand
-field which is equivalent to nvim-lint'scmd
field, but they also have aformat
-field, which accepts said pure-lua function (they also have acondition
-field, which I think could also be useful here)(having a
linter
field (pure-lua) would also allow new linter tools, for-example these two from null-ls, and this one I wrote, just before switching to nvim-lint/conform.nvim)This bit is what is holding me back from writing the injected-linter; I'm not too comfortable adding logic to the core-logic :-)
The text was updated successfully, but these errors were encountered: