Giter Site home page Giter Site logo

dense-analysis / ale Goto Github PK

View Code? Open in Web Editor NEW
13.5K 90.0 1.4K 18.03 MB

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support

License: BSD 2-Clause "Simplified" License

Shell 1.96% Batchfile 0.06% Elixir 0.01% Python 1.04% Kotlin 0.01% Dockerfile 0.05% VHDL 0.01% Racket 0.02% Jsonnet 0.01% JavaScript 0.01% Vim Script 96.64% Lua 0.19% Astro 0.02%
linter vim syntax-checker vim-plugin vim-plugins language-server-protocol neovim-plugin languageclient autocomplete

ale's Issues

Add quickfix support

I addeed loclist support on day 1, but not quickfix list support. Some people will probably like to use the quickfix list. Some support should be added for populating the quickfix list, and for automatically opening the list when there are errors.

Go support

golint and go vet support would be great.

They have relatively simple output -- I would guess golint would produce warnings and go vet errors.

Eslint incompatibility with vim-jsx

Hey there!

First and foremost, thank you so much for your hard and fast work on this plugin, it's really great.

I've ran into the most peculiar issue with using ale and eslint, where the linter will break only when the vim-jsx plugin is simultaneously included. Thought I'd bring it to attention here, although I've no idea why it might be happening or how to go about tracing stacks etc., to try fix it.

To replicate

  • Include vim-jsx via some plugin manager, along with ale.

Thanks,
J.

Install docs would be useful

Currently nothing exists to help a new user to setup the plugin.

Vundle? Pathogen? Required vimrc changes etc etc.

A string for the statusline

A function returning a string usable by the statusline will be very useful (like validator or syntastic does). Should we wait for a stable API before implementing it?

Add powerline segment(s)

I'm going to write powerline segments to display the file status and error message for powerline, like the ones for syntastic.

What API would be the best to query the location of the first and total number of errors and warnigs respectively?

Maybe there should be some lower-level interface of ale#statusline#Status(), it seems very redundant to re-do all that access and sorting logic in python to display it (compare to the syntastic API: g:SyntasticLoclist.current().errors(), g:SyntasticLoclist.current().hasErrorsOrWarningsToDisplay())

Linters for Elixir

  • Elixir (not always useful messages)
  • Credo
  • Dogma (cannot accept files from stdin and covers the same area as mix credo --strict)

Write important tests

I'll list some important tests we should write to kick off the Vader test suite.

  • Unit test the loclist sorting.
  • Unit test the loclist binary search.
  • Unit test handlers in handlers.vim
  • Test that we echo the correct errors based on the cursor position. (Multiple errors on the same line)
  • Test that running a linter on a file updates the loclist
  • Test that running a linter on a file updates the signs
  • Test that linters run when files are opened.
  • Test that linters run when the TextChanged event is fired.
  • Test that linters run when files are saved, when that option is on.
  • Test the status function. (This can probably be tested by setting the buffer loclist global)
  • Test the nearest file search
  • Test cleanup of variables
  • Test the behaviour of g:ale_linters with the Get function.
  • Test the behaviour of g:ale_linter_aliases with the Get function.
  • Test doautocmd behaviour implemented in #104

Feature Request: Lint on save

Would it be possible to create a rule to lint on save only? I tried setting let g:ale_lint_on_text_changed = 0 but then no linting occurs; ideally I would like to only lint on each save so that I have a chance to do everything on my own first and then am alerted of anything I missed (when I save) rather than right away; I considered increasing g:ale_lint_delay but I want the lint to be immediate, just only on save, not right while I am in the middle of typing and fixing things I already know wont work.

So, something like this:
image

p.s. thanks for a fantastic plugin! I was glad to make the switch from Syntastic to the Vim 8 async goodness.

Global variables

Is there any reason for us to use global variables, as opposed to buffer-scoped variables? I think buffer-scoped variables make more sense for our use case, and could be used to simplify much of the code.

How to specify bash for sh files

I want to use only bash to lint sh files (I still have shellcheck installed and don't want to use for now), so which one of the following should I use?

" It should be after the linter name, which is 'shell'
let g:ale_linters = {'sh': ['shell']}

let g:ale_linters = {'sh': ['bash']}

Note that none of the above works.

Set up Travis CI Testing

I have never set up Vim plugin testing on Travis CI before, but I believe it would be wise to set up some CI for this plugin to ensure that the various linters will continue to work, if at all possible.

Vader seems to be the tool to go for, from my limited amount of research. There is also an RSpec option. I do not know what will work best for this at the moment.

If anyone has any suggestions on this, please let me know.

Fix a format for echoed string

Now each linter use its own format for the echoed message, so it will be great to decide and specify only one format to use.

IMHO something like that will be good:

When we know the severity

:[linter-name] Severity - Text

And when we don't know:

:[linter-name] Text

Note that the 1st letter of severity/text is in capital.
I'm thinking that linter-name can be helpful for the file types using multiple ones.

@w0rp If you agree, I can make a PR.

Refactoring

Actually, the plugin is getting bigger and bigger, so IMO we should make some refactoring for the next versions.

  • Create a directory structure more vimish, e.g:
├── ale_linters/
├── lib(scripts?)/
│   ├── stdin-wrapper
│   └── dmd-wrapper
├── doc/
│   ├── ale.txt
├── plugin/
│   └── ale.vim (content of zmain and maybe aaflags.vim)
├── autoload/
│   ├── ale.vim
│   └── ale/
│       ├── aaflags.vim
│       ├── cursor.vim
│       ├── handlers.vim
│       ├── sign.vim
│       ├── util.vim
├── example.gif
├── LICENSE
├── CONTRIBUTING.md
└── README.md
  • Use local variables & functions when we can.
  • Document everything.
  • Test cases, using Vader or the vim 8 testing framework (#7)
  • Use an OOP approach (Not mandatory but make the code more readable)
  • Follow the google Vimscript Style Guide (Vint is following this guide).

What do you think @w0rp?

Add comment headers to each source file

Comment headers to each source file should be added. Most importantly, the authors of each file should be credited in each file. This will help especially as others contribute to the project.

Cannot use jshintrc file

I went through the jshint.vim code and saw it was supposed to either detect a .jshintrc file in the parent directories of the current file, or use the one specified in a global configuration variable.

I did some digging around (not a vimscript expert) and found that the if jshint_config check at (https://github.com/w0rp/ale/blob/master/ale_linters/javascript/jshint.vim#L22) does not work, it should be (according to me) if !empty(jshint_config)

I changed that, but then it was still not OK, so I dug a bit deeper and found that removing the shellescape part at the next line (https://github.com/w0rp/ale/blob/master/ale_linters/javascript/jshint.vim#L23) fixes it. However, I'm not sure if this is the right way to go (the shellescape is there for a reason I guess), that's why I did not create a pull request.

Sometimes tidy does not lint html files on BufEnter event

A strange behavior that can occur randomly.
When opening an existing file, there is no linting before the file is modified.

ale

With verbose set to a high value, I've seen that ALELint(0) is called correctly on BufEnter but no linting so far.

I've tested with a clean vimrc with only ale and different file types, and same issue.


EDIT:

The code from the gif:

<!DOCTYPE html>
<html lang="fr">

  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width; initial-scale:1.0; maximum-scale=1.0">
    <title>A simple title</title>
  </head>

  <body>
    <h1>Foo/h2>
    <p>Sit magni quo cum fugit tenetur commodi Eum labore facilis.
  </body>

</html>

Create better default signs

I wrote this plugin with some signs which are easy to differentiate, but which don't look the best. I think the plugin could use some better default signs and colours, etc. If anyone has found some better characters and colours to use for errors and warnings, let me know.

Additionally, if anyone can think of a nicer looking GIF to put in the README file with some nicer looking signs, I'll take that.

Lessons Learned from Syntastic

Hey there, @w0rp thanks for your work on this.
I just read this thread: vim-syntastic/syntastic#699 and it is VERY INFORMATIVE on the limitations vim has and how far can Syntastic go. He mentions the flaws that they only found out later and etc and still many plugin developers commit the same errors.

So I thought you would like to know those (in case you don't already)...

Cheers

E631: write_buf_line()(): write failed

While using ale in MacVim GUI this message appears in the command line very very frequently. There are also some others I am seeing with a simple .vimrc

set nocompatible
set nu
set runtimepath+=~/.vim.old/neobundles/ale
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
Error detected while processing function <SNR>20_TimerHandler[22]..<SNR>20_ApplyLinter[3]..<SNR>20_ClearJob:
line    1:
E716: Key not present in Dictionary: process 25042 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 25042 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
line    1:
E716: Key not present in Dictionary: process 25043 dead
E15: Invalid expression: s:job_info_map[a:job].linter
line   15:
E716: Key not present in Dictionary: process 25043 dead
line   16:
E121: Undefined variable: linter
E116: Invalid arguments for function remove
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed
E631: write_buf_line()(): write failed 

Vim Version is 8.0.020 and there is no .vim/ for this test (as seen above only ale is being added manually).

Gitgutter is overwritten by ale

When using the gitgutter plugin, which adds git changed/added/removed annotations to the left gutter, ale seems to be in competition for the gutter space. I see gitgutter's annotations flash briefly, and are then overwritten when ale finishes processing with either nothing, or with whatever syntax issues ale found.

Write an option for choosing which linters are run

An option for choosing which linters are run in a vimrc file should be added. The option should look like the following:

let g:ale_linters = {
\    'javascript': ['eslint'],
\    'c': ['llvm', 'splint'],
\}

The plugin should by default attempt to run every linter which can be run when a language is not specified, or the option is not given at all. When a language is specified, only the linters named in each array should be run when analysing a file.

Feature request: statusline lint status option

Would be cool if there was something available to add to the statusline to show lint status; for reference, Syntastic has this:
image

p.s. Thanks for the great work on ALE! I'm really liking it so far; the Vim 8 async is much better than Syntastic and I appreciate that this plugin is more modern + lightweight.

Add coding standards to `CONTRIBUTING.md`

The coding standards should be added to the CONTRIBUTING.md file so everyone knows the rules around indentation, and other parts of syntax humans moan about endlessly.

Attempting to add support for PHP

Hello, I am trying to add support for php with php -l. I've added a directory called php to ale_linters and added a file called php.vim.

Here's my code so far:

if exists('g:loaded_ale_linters_php_php')
    finish
endif

let g:loaded_ale_linters_php_php = 1

function! ale_linters#php#php#Handle(buffer, lines)
    " Matches patterns like the following:
    "
    " Parse error: parse error in - on line 7
    let pattern = 'Parse error: \(.\+\) on line \(\d\+\)'
    let output = []

    for line in a:lines
        let l:match = matchlist(line, pattern)

        if len(l:match) == 0
            continue
        endif

        " vcol is Needed to indicate that the column is a character.
        call add(output, {
        \   'bufnr': a:buffer,
        \   'lnum': l:match[1] + 0,
        \   'vcol': 0,
        \   'col': 0,
        \   'text': l:match[0],
        \   'type': 'E',
        \   'nr': -1,
        \})
    endfor

    return output
endfunction

call ALEAddLinter('php', {
\   'name': 'php',
\   'executable': 'php',
\   'output_stream': 'stderr',
\   'command': 'php -l -',
\   'callback': 'ale_linters#php#php#Handle',
\})

When I run cat myfile.php | php -l I get sytnax errors. But in the buffer nothing shows up.

Some input on Airline

Hey there, I just (vim-airline/vim-airline#1286) posted a PR adding support for ale to vim-airline. Could you take a look on it, and comment on the approach/code?

Alternately, if you feel the API is unstable or it would be better maintained here, it can be included as a part of ale with only minor changes.

Thanks!

Write help files in English

This project needs some help files for the :help command to explain the plugins, and perhaps some of the options. I might also additionally add a section to the README file for the various flags you can set in your vimrc file. The API for adding linters should be explained in detail.

Jobs should be tracked seperately

Getting an error on the latest master:

Error detected while processing function <SNR>105_HandleExitNeoVim[1]..<SNR>105_HandleExit:
line   29:
E716: Key not present in Dictionary: 1
E15: Invalid expression: g:ale_buffer_should_reset_map[l:buffer]

Make a cool logo for "ALE"

I would like to put a cool logo for the project in the README file to show on GitHub. I possess basically no skills for making that kind of art myself. If anyone wants to give it a go, I'll accept any contributions.

The signs are not updated

Is it just for me or what? Starting from 6754b9f, the signs are not updated.

ale

You can see in the gif above that even after correcting the error, the sign is still there.
Reverting back to aebf8e0 make the signs work as expected.

What about the tools not reading from stdin?

I would like to add many linters that unfortunately do not read from stdin (csslint, sass-lint, vint...). Is there any plans or strategy to handle those kind of tools in ale?

In fact, I can easily add them to validator but I prefer to use a solution full vimscript as your plugin.

Add Windows support

Support should be added for running pretty much all of the linters in Windows.

I am working on this now. I initially tried writing a Windows variant of the stdin-wrapper as a Batch script, but it didn't go so well, as Batch is pretty awful. My plan now is to write the wrapper in D, and include a portable .exe file for Windows in this repo. After that is done, there will be some further adjustments to make, around dealing with strange Windows shell escaping issues.

Errors when using ALEGetStatusLine() with airline

Hi @w0rp, I may be wrong but I noticed that when i'm using ALEGetStatusLine() function with airline like this:
let g:airline_section_error = '%{ALEGetStatusLine()}'
then it works good for file types for which i have installed linters, but for other filetypes it throws errors:

E117: Unknown function: ALEGetStatusLine
E15: Invalid expression: ALEGetStatusLine()

I made a screencast with the actual behaviour https://asciinema.org/a/abbk4amukbzrvmgskyjesusd1

Readme updates

Just noting the README needs to be updated with new flags/options, examples such as how to alias filetypes, and that the statusline function needs to be updated.

bundle exec for rubocop

Hey,

I had to override ruby linter command to 'bundle exec rubocop...' but maybe it should be available in configuration.

Alias system required

With my lazy-loading work (and indeed, before it, in the case of the sh linter), shell linter, linters which support multiple file-types are not actually used.

This is presently the case for jsx and zsh. Two solutions are obvious:

  • Create symlinks (easiest and simplest, in my opinion)
  • Create an alias table

I think the symlink approach is more elegant, as it avoids referencing any linters in the core, and can be trivially and transparently managed, eg ln -s ale_linters/sh/shell.vim ale_linters/zsh/shell.vim.

Thoughts?

Nothing beign echo'ed when over error

Hey, trying out ALE now, but it doesn't seem to echo errors nor highlight them when something is wrong. Using vim 8.0 1-22 with newest version of ALE (as of now). No errors or such, I am however using YCM if that could matter. I can post my config if you need, but it's only stuff from the readme.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.