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 Common Lisp with sblint #4061

Open
Jach opened this issue Feb 8, 2022 · 0 comments
Open

Add support for Common Lisp with sblint #4061

Jach opened this issue Feb 8, 2022 · 0 comments
Labels
new tool Support for new linters, fixers, etc.

Comments

@Jach
Copy link

Jach commented Feb 8, 2022

Name: sblint
URL: https://github.com/cxxxr/sblint

I took a crack at adding support locally and (barring the double regex since my regex-fu is weak today) this seems to work ok-enough.

"ale_linters/lisp/sblint.vim
function! ale_linters#lisp#sblint#Handle(buffer, lines) abort
    " General format is
    " <file>:<line>:<column>: <type>: <description>
    " Examples:
    "src/font.lisp:11:39: compiler-error: READ error during COMPILE-FILE: Package SDL2-TF does not exist. Line: 11, Column: 40, File-Position: 307 Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /path/src/font.lisp" {100D616C83}>
    "src/font.lisp:8:0: style-warning: The variable A is defined but never used.
    "
    " compiler-error errors have all that extra redundant junk that shouldn't
    " be part of the description.
    let l:pattern_compiler = '^\(.\+\):\(\d\+\):\(\d\+\): \(compiler-error\): \(.\+\) Line: \(\d\+\), Column: \(\d\+\)\(.\+\)$'
    let l:pattern = '^\(.\+\):\(\d\+\):\(\d\+\): \(compiler-error\)\@!\(.\+\): \(.\+\)$'

    let l:output = []

    for l:match in ale#util#GetMatches(a:lines, l:pattern_compiler)
        call add(l:output, {
        \   'filename': l:match[1],
        \   'lnum': l:match[2] + 0,
        \   'col': l:match[3] + 0,
        \   'type': l:match[4],
        \   'text': l:match[5],
        \})
    endfor

    for l:match in ale#util#GetMatches(a:lines, l:pattern)
        call add(l:output, {
        \   'filename': l:match[1],
        \   'lnum': l:match[2] + 0,
        \   'col': l:match[3] + 0,
        \   'type': l:match[5],
        \   'text': l:match[6],
        \})
    endfor

    return l:output
endfunction

call ale#linter#Define('lisp', {
\   'name': 'sblint',
\   'executable': 'sblint',
\   'command': 'sblint',
\   'callback': 'ale_linters#lisp#sblint#Handle',
\})

It takes advantage of the fact that sblint with no arguments will look in the current directory for any .asd files (typically projects have at least one specifying the project's set of Lisp files) and compile them for linting. I make use of rooter so this works for me even if my lisp files are nested in src/ and my asd file is above that. To make this more robust I think it should try to detect the project root and pass that directory name as a single argument.

While sblint can work on single files it's really meant for whole-project analysis, and ignores stdin so that linting only updates on file save. Perhaps a future improvement to sblint could be to give it an additional parameter specifying a replacement filename (i.e. the active buffer that ALE normally passes over stdin from somewhere in /tmp/) that it can check if it overlaps with a project file inside the asd definition. Or if there is no overlap like in the case of a new file, compile and lint the new file after having done so for the other files listed in the asd.

@Jach Jach added the new tool Support for new linters, fixers, etc. label Feb 8, 2022
Jach added a commit to Jach/dots that referenced this issue Feb 10, 2022
,xg command for specializing generally.
Some slimv adjustments.
Added \sblint command, but using ALE I made something better: dense-analysis/ale#4061
Added vimscript function to convert various kinds of lisp symbols to
string literals.
Added commented workflow for using vim-grepper with vim's built-in
quickfix commands to do things like mass renaming.
Letting vim-rooter defaults be in place.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new tool Support for new linters, fixers, etc.
Projects
None yet
Development

No branches or pull requests

1 participant