emitter: add pad_line_comment

[braydonk]

Added an option to pad line comment by the additional single space in formatted output.

Part of the work for google/yamlfmt#104

[braydonk]

Ah this is a bit too simple, because that spot where the comment is written doesn't distinguish what kind of comment it is.

[badouralix]

Any reason to inject the extra spaces here instead of directly in yaml_emitter_process_line_comment ?
That would avoid having to provide a 0 any time yaml_emitter_write_comment is called

yaml/emitterc.go

Lines 1149 to 1153 in 875dd3d

	if !emitter.whitespace {
	if !put(emitter, ' ') {
	return false
	}
	}

[braydonk]

The main reason is that then I would have to change the logic at line 2007 which checks for the beginning of the line comment to be a #, and if it's not then it inserts # . It's sorta weird logic imo, but in general I tend to prefer stuff like this that simply adds an override to existing logic over messing with it directly. Just want to keep my involvement with the original library to a minimum.

[badouralix]

Got it ! My understanding of this logic is that it applies to non-line comments, since line comments always have comment[0] == "#" and never have breaks, whereas non-line comments can span over multiple lines and handling them requires this logic
Overall I wouldn't have to worry much about this logic for anything related to inserting spaces before writing the comment itself

I have been experimenting with this alternative implementation badouralix@f2c7845 and couldn't find any edge case breaking the behavior of line comments ( haven't opened the pull request though since you opened yours first )
One interesting thing is that the config is explicitly 2 to insert 2 spaces before a line comment, whereas the padding config wants 1 to insert 2 spaces
Wouldn't it be easier to keep an alignment between the config and the number of spaces rather than having a discrepancy ?

[braydonk]

The reason I had kept with the idea of "padding" and making it a padding of 1 space over the 1 space that automatically gets inserted. But I can see how that would be harder to explain that in documentation vs the default of 1.

That being said, I like your implementation better. I have a couple of comments, but I think overall yours is better and I'd rather accept that in favour of my version. Could you open a PR with it and add me as a reviewer?

[badouralix]

Just opened #16 but it seems I cannot add you as a reviewer 🙈

[braydonk]

Thanks! Not sure why it doesn't let you add me as a reviewer, but I just requested myself instead.

[braydonk]

Closing in favour of #16