👍 I think this is absolutely on the right track!

Let me know if I can do anything particular to help this work along.

@rmosolgo could you please approve CI pipeline run? Thanks

Next steps for us is to implement support for multi-line comments, we'd need to be able to parse them. For printing (output), we were thinking of for allowing newline characters if user wished to have multiline output. This would mean the comment argument could accept value such as: "first line\nsecond line" and the output would be:

# first line
# second line

We think it's good enough API for users to format it this way instead of some complex solution, such as allowing to pass lists or having some kind of automated mechanism (e.g. break after 80 chars).

If you think that printing multiple line comments is something that's not needed or wanted, we're OK with not having it.

I agree that working from line breaks is the right way to render multiline comments. Ideally, GraphQL-Ruby would be able to parse SDL with multiline comments and print them back out exactly as they were originally written. (For your use case with es-lint, that might even be a hard requirement -- we don't want those directives getting merged with the explanatory comments above them, right?)

Ideally, GraphQL-Ruby would be able to parse SDL with multiline comments and print them back out exactly as they were originally written. (For your use case with es-lint, that might even be a hard requirement -- we don't want those directives getting merged with the explanatory comments above them, right?)

Yeah exactly, we should respect that during parsing that's for sure. Yes for eslint, it's important the specific comment needs to be placed right above the statement it's related to.

We'll try to polish this first and have the tests pass, which will probably require us to figure out multiline comments in the process 👍

@rmosolgo 👋 hello, is it possible to approve running pipelines on this PR? We're in the process of fixing specs and it'd be nice if we could see results in CI. 🙇

👀 I see the button to allow CI once, but I'm not sure how enable it for a PR. I couldn't find a doc from GitHub on how to do it -- do you know how?

@rmosolgo Hm I thought there might be some settings in repository. I only found this but not sure if it helps. Anyway, thanks!

Ah... yes, there is a setting there: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#controlling-changes-from-forks-to-workflows-in-public-repositories

I switched it so only "new GitHub accounts" need me to approve them. Hopefully that will do it 🤞

Wrong button 🤦

@rmosolgo Hello, we've got to a point where most of the tests are passing (of course the changes themselves are far from final) but we are stuck on the c-parser integration. It's a little mysterious how it works to us and we could use some guidance how to fix it and what the best approach here would be. Could you help us please?

cc @comatory