ALE config file?

[spenserblack]

Motivation

I have a TypeScript project, and Deno installed. I do not want Deno to be used as a linter for this project. But I don't want to disable Deno in my vim configuration in case I work on a Deno project.

Idea

Like how EditorConfig can read a file in a repository (root file has root = true to tell plugin not to look any higher in the tree), I wonder if it would be reasonable for a config file for ALE to set configurations per repository/directory instead of per buffer/pattern.

[w0rp]

This has been raised many times, and my recommendation is to use whatever Vim plugin to provide configuration specific to Vim per project, and use that to set options for ALE. ALE doesn't need to have its own implementation of project configuration files when other plugins can handle that.

[w0rp]

Hmm. I'm thinking about this again. Could you open an issue for ALE adding support for specifically EditorConfig and tag me? I think that would be entirely reasonable, and a good developer experience.

[Flimm]

I'm not sure if .editorconfig files are meant to contain configuration that are specific to particular editors. It's supposed to be configuration that works across all text editors, in my opinion. I haven't given it much thought, that wasn't what OP was asking for, they were asking for support for a file like .ale or something, inspired by .editorconfig. If you're saying that vim-ale should understand the standard EditorConfig options like indent_size, tab_width and so on, that's interesting, but I don't think it is what OP was asking for.

[spenserblack]

Coming back to this discussion I honestly don't know why I brought up EditorConfig specifically as an example. Especially since an .editorconfig file is kind of the opposite of an editor-specific (not just that, but plugin-specific) config file. I still believe allowing for a project-wide config file is useful, but since this discussion is a duplicate I won't push the issue much further. I'm having trouble finding the duplicates, though, as my search is returning a lot of false positives.

But I believe @w0rp was talking about making ALE be able to read from .editorconfig (this sounds like a great idea to me BTW). If ALE starts supporting EditorConfig then you might want to see about adding ALE to EditorConfig's list of 3rd-party plugins so it's discoverable 🙂

[w0rp]

I am often in the position of skipping to the conclusion without explaining the logic. The OP is asking for a very different thing that I suggest is already better handled by writing ftplugin code, but I have had a brainwave from this thread. 🧠 Discovering and executing Vim or Lua scripts presents the problem of apply-eval style security issues. Very hard to implement loading a shared configuration file via a scripting language without adding security concerns. (Not that ALE is that security focused anyway, as we find and execute pretty random executables.)

1. EditorConfig is terrificially easy to write a clean room parser for, is an already accepted standard, and keeps to a strict and simple set of rules.
2. Neovim already supports EditorConfig.
   1. We can potentially skip all EditorConfig logic in ALE in new enough Neovim versions and rely instead on the Vim settings Neovim will set as a result of its own EditorConfig handling.
   2. The implementation across the codebase and with specific fixes for particular linters and fixers can use the Vim settings instead of pulling values directly from EditorConfig so all users benefit, even those without EditorConfig files.
3. Automatic EditorConfig handling and modification of settings based on EditorConfig can become a general-purpose feature of ALE all users get by default bundled in with ALE.
   1. We, as we always do, will add a setting to disable this feature.
4. There's a single filename to search for (.editorconfig), and we can cache the probably synchronous logic to find configs with a TTL where files are not found to avoided repeated IO.
5. The files are likely to also exist in projects, so ALE starts behaving better automatically in some cases.
6. Where people must be trained to add shared configs, they are not "ALE-specific," but actually teach people to use a much wider and more commonly accepted standard.
7. Ongoing maintenance won't become a complicated nightmare, which is a huge plus.

[w0rp]

https://github.com/editorconfig/editorconfig-vim Doing a little more research, this is already done! Just use this one. I'll just open an issue to make sure ALE respects line length in linters and fixers, as configured in Vim, and to document to use this plugin if you aren't already using a new enough Vim version.