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
Only run some linters when files are saved #333
Comments
Part of the behaviour here would be that syntax checking and so on could be done as you type, and then tools which perform static analysis and so on could run after you save a file. The commit above changes the default settings so linters run on saving automatically, unless you turn that off. |
Makes sense, and it's actually how I'd like to run all my linters. I actually disagree with it being preferrable to lint before save. I have probably more reasons than I can immediately enumerate, but the most important that come to mind are that when I save, I expect: a) the work is recoverable, and that it becoming recoverable is not interrupted by anything but major system problems, b) i have more things watching for saves than linters. As an example, my current preferred setup is to have outboard test executors, and inboard asynchronous linters. Not everyone will agree, but this is my position. |
Different users want different things. If you write primarily JavaScript and use Generally, you should get information about syntax errors pretty quickly, and information from static analysis when you save a file. |
If you only want to check your files when you save them, set those options. let g:ale_lint_on_text_changed = 0
let g:ale_lint_on_save = 1 |
Thanks. I indeed have used those options. I was just explaining my use case/desires. For me, even when writing JS and other such things that can be more dynamically linted, I still often don't want any interruption, visual or otherwise until I save - it's at the point of save that I'm effectively saying "ok, you can interrupt me now". That's just my preferred workflow, though. |
I think the key for text editors and plugins is to offer some sensible defaults, but definitely a wide array of options. Everybody is different. |
I just thought of something that is important to handle here. Errors and warnings for linters run only when files are saved should probably be preserved until you next save the file, while other linters can run as you type. I believe it's possible to support that, but it won't be totally easy. |
I originally conceived of this as "only run on save," but I have since realised that what it actually should be is "only run from disk." I haven't figured out a short enough phrase that explains it to get a good option name, but it's running tools on the version of the file that is on disk, only when a file is first opened, or when a file is saved, maybe when a linter is run manually. The errors/warnings which are set for linters which only run when a file is opened or saved probably ought to stick around until you next run those linters, which is again not straightforward to handle. |
I think I'll just call the option |
I have created a wiki page for tracking this. I think that will work better for collecting my thoughts, and planning done. |
The |
Is there a easy way in vimrc to disable it ( |
Wiki information: here
I have opened a branch for supporting an option for only running some linters if they are configure to only run when files are saved. See the diff here: 7726c0f
I believe some linters might only work properly if they are run on precisely the file on disk you are editing. Preferably, it will be possible to check a file with a tool before changes have been saved to disk, and most linters should be implemented this way. However, it is possible that some tools just won't work that way, no matter how hard you try.
I'm considering setting some linters, notably
pylint
, so they will only run when files are saved, maybe also when files are opened and the file is readable. (The option could be namedlint_from_disk_only
, or something else if someone can come up with a better name, if that's the behaviour.) The commit above has a quick example of what the behaviour might be like.What do others think of this idea?
The text was updated successfully, but these errors were encountered: