Add commands for jumping through problems in all buffers

[w0rp]

ALE offers some commands for jumping through errors within a single Vim buffer, such as :ALENext and friends. Vim offers :cnext and :cprev for jumping through errors across all buffers, using the quickfix list. :cnext and :cprev don't work with ALE, because ALE often resets the quickfix list, which resets the position in the quickfix window.

Some new commands could be implemented for jumping through errors across all buffers. The process would work like so:

1. Invoke a command like :ALENextGlobal or whatever the command ends up being called to jump to an error.
2. Combine and de-duplicate the lists from all buffers, sorting the lists by the absolute paths to the files.
3. Find the relative position in the list with a tuple (filename, line, column) and jump to the position in that file.

[GeneZharov]

Why is this issue closed? Is it going to be implemented? Or is there any other way to see and fix all errors in a project?

[w0rp]

The issue isn't closed, it's open. Nobody has worked on it yet. If someone submits a pull request for this, I'll have a look at it. I probably won't be working on this myself.

[fenuks]

Hello, I've been thinking about adding ikos support to my favourite editor and my favourite linting plugin, but that particular linter is rather meant to be run on whole project with ikos-scan command. There is ikos command that can be used on single file, however it seems one cannot pass any compilation flags to it, which renders it useless for any non-trivial program. It can be said about other linters as well (for example, infer is meant to be run on whole project as it makes use of project's build system).

From my point of view, ale misses features three useful features found in other editors, and ability to run linter across whole project is one of them. Other than that, fixing issue under cursor (if supported by linter, TypeScript server seems to have this feature that is exposed in VSCode editor), and fix specific category of issues (again, it is possible with VSCode and Typescript server).

While I don't promise anything, I plan to investigate this problem closer and perhaps come with solution, since I consider whole project linting highly desirable feature to have.

[w0rp]

I've thought about adding support for running linters for entire projects. For now, run the linters outside of Vim, with a script.

[fenuks]

Thank you, glad to hear that such option potentially will find it's way into ale!

[w0rp]

I can't remember if I did ever open an issue for that, but I'll share my thoughts here. I think if ALE did support the option to run some linters over entire projects, it would work like so.

1. Linters would require that a second command be defined for running linters on entire projects, and probably a project path detection function be defined for them.
2. Not all linters would support running on entire projects, because not all of them do.
3. Running linters on entire projects would only work off files on disk, never from something in your Vim buffer, never something as you type.
4. The results could be displayed in files in the usual ways, and would probably go into quickfix.
5. Results from the entire project and in a buffer would probably conflict with one another, and resolving those conflicts would be very difficult.

There are my thoughts. I probably won't implement it myself, as I don't have a personal interest in doing so, but someone else might feel like picking it up some day.

[w0rp]

Generally the goal of ALE is to show some problems in files you are working on, not stats from a whole project at once, and that's all I really care about.

[fenuks]

I began toying a bit with this (nothing yet to near to working), and here are my few observations.

1. Project linters would have to populate quickfix, that can cause problems for these that configured ALE to use quickfix for buffer linters
2. I think that most linters can be run on whole project, if not supported directly by linter, then for each suitable file in project
3. Configuration might be problem. For example, clazy linter uses different executable name for stand-alone linter (clazy-standalone), and different for project (clazy). That means many adding extra configuration keys for many linters. To make this worse, certain linters, like clazy, require that, say, cmake project is reconfigured with it as CXX compiler. Perhaps prepare_linter or such command will be needed. In combination with out of source builds, that could potentially work (generate project in temporary dir, and then execute linting). I think there might be conflicts in certain linters, for example infer is invoked via infer run -- build_command, and e.g. spotbugs also utilize project build system, therefore I'm afraid they can't be run simultaneously. As far I know, ALE has no way now to indicate two linters are conflicting in a way.
4. Project linting should be run only on demand, as they most often computation expensive.
5. I think it might be necessary to keep project linters and buffer linters separately because their internal representation, I think, will be slightly different (in my experiments, I decided to create another variable called let s:prject_linters = {} as I think, trying to support both global and buffer linters having same structure will complicate it greatly, but I might be incorrect).

Generally the goal of ALE is to show some problems in files you are working on, not stats from a whole project at once, and that's all I really care about.

I agree, but it is also useful to perform whole project linting once for new projects, or project that you collaborate with other people that might introduce new problems, etc.

[w0rp]

The more wordy parts of what you said essentially demonstrate why ALE only looks at one file at a time. It's far easier to do.

[fenuks]

And looking at current file is what people usually want, but I think ALE already provides solid machinery to build upon project linters. :)