format comments with consistent spacing

[macmoritz]

Feature

Normally comments are started by a prefix, in protobuf it is //, followed by a space and the content.
Sadly buf format does not fixes missing or multiple spaces.
Sadly the space is not defined by the language guide but I think it is best practice to add a space. Therefor I am fine with an optional argument or config option.

Example

syntax = "proto3";

package test.v1;

//no space (incorrect)
// one space (correct)
//   multiple spaces (incorrect)
message TestMessage {}

Expected

Expected after buf format file.proto:

syntax = "proto3";

package test.v1;

// no space (incorrect)
// one space (correct)
// multiple spaces (incorrect)
message TestMessage {}

Any thoughts are welcome!

[bufdev]

Multiple spaces is definitely OK and expected - people use this for indentation all the time, including for ie implicit code blocks and inline code (given that Protobuf doesn't have a defined comment structure). Here's a ton of examples: https://github.com/bufbuild/protovalidate/blob/main/proto/protovalidate/buf/validate/validate.proto

Changing //foo to // foo may have other unintended consequences. People use //foo for thing like //nolint or other functionality that they automatically parse (whether they should or not), and for commented out code.

I'd be overall uncomfortable with this change. Additionally, we have made a point of not allowing configuration of formatting, similar to Go's stance, i.e. there is one way to format things, for better or worse.

[macmoritz]

You are totally right with multiple spaces. Totally forgot about the indentation.

I get your point with macro-like comments (f.e. // nolint), but are there any usages of these in Protobuf files? Even adding a space should be no big deal for the tools.
Also there are inconsistent formatting in the provided example, for example:

// `max_bytes` specifies that the field value must have no more than the
//specified number of bytes. If the field value contains more bytes, an
// error message will be generated.

These even occurs a few times, I've used ag --proto "\/\/\w+ (ag to find these (thanks @benedikt-bartscher).

I like the no-config approach, but I am not comfortable with missing spaces.
Maybe we can find a compromise?