Introduce a LineSuffix Doc

[JohnnyMorganz]

I'm currently thinking about using pretty.rs for one of my projects, but one thing holding me back is that I can't seem to find a nice way to handle comments currently. Trailing comments can be quite a pain, and you don't want them to be introduced in between code, rather pushed towards the end of the line and then printed there.

From what I can see, there isn't a simple way to do this (please let me know if I'm missing something!). Prettier implements a lineSuffix and lineSuffixBoundary Doc, which places the Doc into a buffer and then outputs it just before a new line - which would immediately help with this problem.

[Marwes]

Can't say I have had this problem, my line comments always have a hardline after them so it isn't possible for code after them on the same line (as the hardline forces a newline). Do you have an example of how this issue occurs? The Prettier example seems really strange to me as they add the comment inbetween tokens.

["a", lineSuffix(" // comment"), ";", hardline];
// Why not
["a", ";", " // comment", hardline];

[JohnnyMorganz]

An example, in Lua

foo( -- comment
    "bar"
)

I want this to be collapsed onto a single line, but I can't add a hardline at the end of the comment here
Without anything, it would collapse as:

foo( -- comment "bar")

But ideally, it should be buffered so that it outputs something like

foo("bar") -- comment

[Marwes]

That seems surprising to me, personally if I placed a comment like that I would expect the comment to just prevent the function call from appearing on a single line. The comment could even be explaining something about the argument itself, in which case moving it out and after the call loses the intent of whoever wrote the comment.

[Marwes]

Adding something like this could still be useful, but I want to make sure it targets the right issue here, and perhaps other similar problems as well.

[JohnnyMorganz]

Hm, I've been rethinking this and I actually do agree with you there - I should probably be leaving comments as close to where they are originally.

I guess another place where this could occur would be when a user inputs

print"foo" -- a comment

where omitting parentheses goes against the code style enforced, so it would want to be reformatted as

print("foo") -- a comment

but would currently be reformatted as

print("foo" -- a comment)

I also just saw your "Why not" comment in your original reply. In this case (atleast, for the current way my formatter is setup, which could theoretically change), the formatting of the string literal, which would be "foo" -- a comment, and the actual function call, print(...) are conducted by two separate methods, as they are separate parts of the AST. This would mean, for each formatting method, I would need to get the Doc I wanted + a list of any comments which I need to move around, but then, there may be places where the comments don't need to be moved, such as

local foo = "bar" -- a comment

I guess it is up to you if you think this is in scope for pretty.rs to handle instead, and I understand if it isn't - I could probably work my code around for this.

[Marwes]

I think you may be able to hack into what you want by implementing https://docs.rs/pretty/0.10.0/pretty/trait.RenderAnnotated.html yourself and attach the comments as annotations. Then the renderer would buffer the comments until write_str sees a newline after which you also flush the comment(s) to the inner renderer.

Maybe that breaks down at some point but it could be a POC of this solution.

[JohnnyMorganz]

Alright, I'll check it out and see how I get on (it may be a while as I'm currently working on some other stuff right now). Thanks!