dense-analysis

ale

Vim Script2017–2025

dense-analysis / ale

ale

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

Explore on GitHub Read Hacker News discussions

34Distinct people

41Mentions

1Explicit recommenders

14KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

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

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

Close but not close enough. For example: in VSCode you can select/hover over any expression and it’ll tell you the computed TypeScript type. None of the current language server…

dmitryminkovsky used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

neoclide/coc.nvim · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:03:30 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year41 dated mentions

Observed mentions: 2017-01-02 16:20:59 UTC to 2025-07-22 04:34:22 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	3	2	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	4	0	4
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	7	0	7
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	9	1	8
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	2	0	2
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	8	1	7
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	5	0	5
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	0	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	0	1

What Hacker News says

8 sources

isomorphic·Dec 21, 2022

If you're looking for IDE-level language assistance, I can't help you, but since you mentioned nvim: I use regular vim with CoC / Conquer of Completion (vim plugin; LSP server, may not strictly be necessary for nvim), Solargraph (Ruby Gem; language server), and Rubocop (also a Gem) for linting. I previously/still use ALE (vim plugin; Asynchronous Lint Engine) because I haven't gotten CoC+Solargraph to play nice with Rubocop, probably due to something silly. https://github.com/neoclide/coc.nvim https://solargraph.org/ https://rubocop.org/ https://github.com/dense-analysis/ale My impression with all of this running under MacVim... it's plenty responsive. It can take a while for Solargraph to index everything on startup if you're working in a big project; once it loads, it's snappy. (There's probably a way to cache that startup scan.)

In Ruby delights built into the language

lizardking·Oct 15, 2022

I use a lot of them, many specific to my work, but here are some of the ones that I think will most improve the quality of life for most developers. - For a plug-in manager I user packer - For file/text search I recommend telescope (https://github.com/nvim-telescope/telescope.nvim) - Copilot (https://github.com/github/copilot.vim) - Nerd tree for file browsing (https://github.com/preservim/nerdtree) - commentary for commenting (https://github.com/tpope/vim-commentary) - ALE for linting (https://github.com/dense-analysis/ale) - Mason for installing LSP servers (https://github.com/williamboman/mason.nvim) Once you have the proper tooling in place you can do pretty much everything in vim that you are doing in vs code or intelliJ. I've just started using it for most of my dev work recently and I have found ThePrimeagen's youtube videos on vim

Read the rest

to be a great resource. Series on using vim as you editor (https://www.youtube.com/playlist?list=PLm323Lc7iSW_wuxqmKx_x...) Introduction to setting up your vim configuration (https://www.youtube.com/watch?v=x2QJYq4IX6M&t=512s) I recommend giving it a try. The process of learning it all was fun, and as you may have heard you can eventually get pretty quick using Vim.

In Ask HN: Is it still possible to live in a terminal?

djhaskin987·Sep 7, 2022

Sorry for all the edits, just want to write all my thoughts down in one place. 1. Various interactions I frequently have: - `va(C-cC-c`. Select the current parentheses text object (s-expression) and send it to the repl. -`C-aC-a`, switch to repl to view output, interact with debugger, etc. - `ggVGC-cC-c`, select the entire file and send it to the repl. - I've never done this one but since you mentioned it as useful to you: `?^(<CR>va(C-cC-c`, evaluate a top level form. Not perfect, but probably good enough especially if a line formatter is used to enforce sane indenting like this one for Clojure[6]. If a line formatter does not exist, the usual `ggVG=` built-in vim indenting works just fine. - `:set makeprg=<command to run unit tests with line numbers>:make`. Batch error reporting and fixing, very useful[1]. In Clojure, e.g. `lein test` w

Read the rest

ith some additions to set error format might be the `make` program. vim-slime does not have an understanding of s expressions but vim itself does, using the parentheses object. See `:help text-objects`. I like that vim-slime does not have this understanding because what if I'm using it with Ruby or something. But vim support of text objects is good enough that it's never a problem. While I'm on the subject, `])` and `[(` searching for parens in vim is awesome. Vim operates using an entirely different set of values than emacs. Selecting and searching for text should not be the purview of a plug-in, it should be built into the editor. Compiling code should be delegated to compilers. Vim does a great job of this kind of separation of concerns, it is the Zen of vim, its core philosophy. Emacs is great and it works fantastically, it just operates using a different philosophy. 2. I work more in Clojure but I'm trying to get more into common lisp. Clojure has suggestions in neovim via language server protocol[2]. The suggestions are very good[3]. This is not as developed for the common lisp story[4] but I'll try it out and see how good it is. I've never had much patience for autocompletion. I don't even like it when the editor puts in pairs of parentheses when I've only typed the first left parentheses. Vim does have autocomplete through the language server protocol, but I don't use it. Regarding suggestions as I type, there's ale[5], but I think I would find suggestions as I type a little too distracting and might slow me down. I find the normal LSP stuff to be good enough. 1: https://vim.fandom.com/wiki/Errorformat_and_makeprg 2: https://blog.inkdrop.app/how-to-set-up-neovim-0-5-modern-plu... 3: https://github.com/clojure-lsp/clojure-lsp 4: https://github.com/cxxxr/cl-lsp 5: https://github.com/dense-analysis/ale 6: https://github.com/venantius/vim-cljfmt

In From Common Lisp to Julia

aidenn0·Jun 17, 2022

vim-ale[1] combines a LSP client with the ability to shell out to linters and supports vale 1: https://github.com/dense-analysis/ale/blob/master/supported-...

In Writing like a pro with Vale and Neovim

jeremija·May 7, 2022

I've been using ALE for years and even contributed to it: https://github.com/dense-analysis/ale

In I’ve spent my Easter break customizing Neovim

a-t-0·Feb 20, 2022Submission

Ask HN: Let's build Checkstyle for Bash?

After working with Bash and Shellcheck for a few months, I noticed I could improve my code quality by making it compliant with the Shell Style Guide by Google [0]. While working on that, I thought some aspects of this Shell style guide can be verified automatically, granted some assumptions/opinions are formed. So I looked around for linting tools and autoformatters for Bash: Shellcheck: https://github.com/koalaman/shellcheck From Asynchronous Lint Engine (ALE): https://github.com/dense-analysis/ale/blob/master/supported-... - bashate: https://github.com/openstack/bashate - cspell: https://github.com/streetsidesoftware/cspell/tree/main/packa... - Bash Language Server: https://github.com/bash-lsp/bash-language-server - shell -n flag: https://www.gnu.org/software/bash/manual/bash.html#index-set - sh(shfmt): https://github.com/mvdan/sh - shd

Read the rest

oc: https://github.com/reconquest/shdoc From this stack post [1]: - checkbashisms: http://man.he.net/man1/checkbashisms - shlint: https://github.com/duggan/shlint (archived) Prettier: https://marketplace.visualstudio.com/items?itemName=esbenp.p... Within all these linters and auto-formatters I did not find checks that enforce, for example, the Function Comments of the Shell Style Guide by Google: All function comments should describe the intended API behaviour using: Description of the function. Globals: List of global variables used and modified. Arguments: Arguments taken. Outputs: Output to STDOUT or STDERR. Returns: Returned values other than the default exit status of the last command run. Hence, I thought we could make a Bash linting tool that verifies compliance with the Shell Style Guide by Google. To do so, a brief start was made here [2]. It identifies/lists elements in that style guide that may be verified automatically. Since Bash has been around longer than me, I think there may be some people better suited for the development of this enhanced linter. Hence, I thought it might be wise, for impact and usability, to share this idea here. What do you say, HN? [0]: https://google.github.io/styleguide/shellguide.html [1]: https://stackoverflow.com/questions/3668665/is-there-a-stati... [2]: https://github.com/TruCol/checkstyle-for-bash

59 points · Open discussion

camgunz·Feb 2, 2022

Oh no, the nice thing about it is you can basically configure it to do whatever you want. You can choose linters or fixers, lint/fix on save or on a configured "I've left insert mode" lag, etc. etc. It's actually really amazing [0]. One of the things I've really enjoyed about the Free Software ecosystem is choice, like mostly before Rails the attitude was "we don't presume to know the best anything, here are some options." I'm not saying there aren't tradeoffs (complexity, bitrot, 7 half-baked options vs. 1 incredible one), only that I kind of low-key resent the "opinionated" software that's out there. I guess I don't really see it as opinionated (like I think Rails' convention over configuration was actually a pretty good idea and exemplifies the "execute" phase of the explore/execute cycle of tooling), I see it as "flashy and targets th

Read the rest

e 80% use-case to get mindshare". To be clear, I don't think rust-analyzer is that opinionated or flashy or lazy. I think it's awesome. But Rust's linting story is essentially "why would you use anything besides rust-analyzer, language servers are awesome and have no downsides." Which like, yeah they do. [0]: https://github.com/dense-analysis/ale/blob/master/doc/ale.tx...

In Rust extension traits, greppability and IDEs

camgunz·Jan 30, 2022

Yeah no you're definitely right, I'm definitely not in the golden path for Rust dev. I guess my quibbles (which I would cop to being quibbles... I think anyway) are: - I'm already using 'cargo check' as my linter (rustc doesn't understand modules, seemingly). - My setup works for JavaScript/React/Svelte, SQL, C/C++, Python, and Go. - It can't be the case that (Neo)Vim + Ale [0] is arcane. Also the link in "Tools" from rust-lang.org goes to the rust.vim repo, which defaults to Syntastic, which I'm pretty sure has the same issue. I don't necessarily think I should extrapolate from my experience to a broader "Rust is different for little/no gain" critique I've made in the past, but I sure want to haha. And to kind of anticipate a little, I wouldn't blame Ale here because--again--it works for everything else. But anyway, yeah I've mostly give

Read the rest

n up on linting and I just run 'cargo check' in a terminal buffer now. It's probably something as simple as adding a command-line argument to... idk cargo or rustc to make the additional "help" format a little more amenable to Ale? Maybe I'll take a crack at it when I get some time. [0]: https://github.com/dense-analysis/ale

In Rust extension traits, greppability and IDEs