If we're going to have an option for one machine talking to another, we should solve all ambiguity problems, like use json output or something. could you parse json output in your editor plugin?

one concern with ambiguity is that file names can contain any byte sequence (in Linux, for example) except '\x00', even non-utf8 byte sequences, so it is fundamentally incorrect to use '\n' and ':' for delimiters.

if course, this is obscure enough that the human friendly output doesn't need to worry about it. but if we're going to make something machine friendly, let's actually do it right.

Another thing that we already have that might solve this is --color off. The C++ compiler supports this already and will output errors in the same format as your example above. I intend to implement this in self-hosted as well. In fact, if you don't supply this option, the default is auto which will give the alternate error message format when stderr is not a TTY. I believe this would activate when using zig fmt in a vim plugin.

I realised when testing the vim plugin I was getting a stack-trace due to a bad command invocation that was tripping me up. It is probably the case already that you get something moderately okay as is. The main difference in this PR then is the dropping of the notes in the output, which isn't as relevant in an editor when you have access to the line/col.

@thejoshwolfe Those are good points. I think given the outstanding questions/edge cases here I'll close this PR and make do on the editor side until we have a more robust solution. I think providing a the output as JSON would be suitable.

Just pushed this:

I think that should be everything we need for the vim plugin:

• errors that the plugin can consume (should be the same format as the go vim plugin code that you forked from)
• robust implementation of zig fmt