One of the interesting questions for the new error format is how much to retain compatibility with existing editors. There is a sort of de-facto convention that many compilers and other tools (though certainly not all by any stretch) use which looks like:
filename:line:col: error: message
Many editors have builtin support to look for this pattern out of the box in compiler output. Many editors are also extensible (e.g., emacs has a list of regular expressions that one can add to). I am not sure how many are not extensible, but even if they are, users may not have installed plugins.
The new error format diverges from this format in order to make things more readable. The new format looks like:
error: message --> filename:line:col 3 |> quoted text
The advantages of this for humans are that it makes the error message easier to find, and also means that long filenames don’t cause the message to be indented way over to the right.
Right now, I have no Rust support in vim (because the Vim mode for Rust isn’t packaged in Debian), and I regularly use
:make build; I can also log the output of a build and run
vim -q build.log.
There are a few options on the table:
- Detect if stdout is a tty and emit a slightly different format in that case.
- Use an environment variable to signal the desire for a different format.
- Just adapt editors to the newer format or to use json (perhaps infeasible).
If we do adopt an “editor friendly” variation on the different format (i.e., other than JSON), it is also a bit of an open question as to what it should look like. It’s clear it should have the filename/line-number easily extractable, and probably the message as well. But what else you want seems to depend on the editor. e.g., for emacs, I really want to see the human readable output just as it looks now, perhaps with some prefix, so that in my compilation window I get to enjoy the new output. That led me to suggest a header like:
filename:line:col: error: message error: message --> filename:line:col 3 |> quoted text
But this has the downside that the details are duplicated, and worse, naive tools may count each error twice (once with the
filename:line:col: part, and once where
--> is considered part of the filename).