Vertically align self-spec for better readability

[eugenesvk]

Forced indentation of comments was making it rather hard to get an overview of the spec, so when familiarizing myself with your interesting project I've vertically aligned the spec and made it vertically "shorter" to be able to push all the comments off-screen by disabling wrapping (and only enabling it when I need to get info for a specific rule) so that the self grammar looks something like this

Unfortunately, this seems to break comment highlighting on GitHub, which might be a dealbreaker (or you might dislike this style anyway)

[jvanstraten]

I'm generally not a big fan of relying on line wrapping in code, but I also never really liked what I ended up with, and with wrapping disabled I can't deny that yours looks much nicer. So maybe we should just go with that.

That being said, the /**..*/ docstrings are part of the grammar, though. See the doc rule. The intention is for them to be propagated to the grammar specification in the target format (antlr, flex/bison, etc) or generated documentation, while // and /*..*/ comments are simply ignored. I haven't looked at the grammar in a while, but my intuition is that we could probably add a /// comment type that acts as a trailing end-of-line docstring, in order to preserve that functionality?

In terms of learning curve and readability, I wouldn't consider this project all that newcomer-friendly at all yet, so I applaud your effort! This is one of those things that I wish existed but (as far as I was able to find) doesn't/didn't, but is just a bit too generic to justify working on professionally. Not to mention that I'm no longer working on the project that I needed it for. But if you have need of it and would be interested in continuing this effort, let me know! I'm open to doing a voice call sometime to exchange ideas.

[eugenesvk]

/**..*/ docstrings are part of the grammar, though. See the doc rule

Well, but Github doesn't care :)

. The intention is for them to be propagated to the grammar specification in the target format (antlr, flex/bison, etc) or generated documentation, while // and /../ comments are simply ignored. I haven't looked at the grammar in a while, but my intuition is that we could probably add a /// comment type that acts as a trailing end-of-line docstring, in order to preserve that functionality?

I've changed the comments to reflect // → /// and /*→/** so that it's ready whenever it's added

Not to mention that I'm no longer working on the project that I needed it for.

Yeah, saw your comment in another parser repo, but I was just in that learning rabbit hole, so it didn't matter

But if you have need of it and would be interested in continuing this effort, let me know!

Sorry, can't really help here, know little of parsing/Rust, was just on a learning trip, but ↓ indeed

This is one of those things that I wish existed but (as far as I was able to find) doesn't/didn't

In those rare cases where I'd need to do some parsing/syntax generation this seems to be exactly like the friendliest way to go instead of all that combo regex nonsense with its gazillion rules. (there is something similar for Sublime Text - a tool that can generate syntax from EBNF-like grammar, but it's a bit buggy)

[jvanstraten]

In those rare cases where I'd need to do some parsing/syntax generation this seems to be exactly like the friendliest way to go instead of all that combo regex nonsense with its gazillion rules. (there is something similar for Sublime Text - a tool that can generate syntax from EBNF-like grammar, but it's a bit buggy)

Out of the tools I've used, I've found ANTLR to be the most beginner-friendly when it comes to writing the parser rules. The grammar specification here is mostly based on that. Getting it to actually generate a parser for you is a different story, though... Maybe someone somewhere made a frontend for it to play around with grammar specifications and parsing? I'm not very good at searching for these kinds of things, I just get bored after 5 minutes and then spend 5 days writing my own thing instead (if at all possible).

I've never dabbled in syntax highlighting rules and editor services though, which I'm assuming the Sublime thing is for. I've only used ANTLR, flex/bison, various small language-specific parsing projects (mostly based on parser combinators), and ad-hoc parsers based on regexes for simple things.

I've changed the comments to reflect // → /// and /*→/** so that it's ready whenever it's added

Thanks! This PR might sit around for a bit though because I'd rather have the /// rule in it and integrated properly before merging, and I don't have a lot of time right now. But thanks for your input and interest in the project!