[v2] more predictable slashdash

[zkat]

Fixes: #401

[zkat]

Alright, this is ready. I actually really like these changes, but I could use a second set of eyes. Getting rid of the weird optional/required-node-space shenanigans and not treating slashdash as grammatical whitespace really simplified things, imo. So, as far as the parser is concerned, /- is a full node, it's just one that won't show up in the post-parse document data.

[zkat]

also worth noting: This restricts /- { child1 } to only being present after props and arguments, so the following is not legal:

node /-{child1} foo;

but this is:

node foo /-{one} {two} /-{three}

I believe this is what you were hoping for, @tabatkins?

[tabatkins]

Very minor style nit, otherwise r+

[tabatkins]

Just for consistency, I'd move the optional slashdash to here, rather than putting it into node-prop-or-arg.

[zkat]

Sounds good. Additionally, I just realized I didn’t put any space allowances around the /-. I’m thinking of making it like:

slashdash := '/-' line-space*

Which means that these would both be legal:

// Very reasonable, IMO
/-
node 1 2 3

// interesting and I think acceptable—it means you can use them like esclines:

node 1 /-
2 3

We can totally ban the second behavior but I think it’s better than having to special case allowing esclines after the /-. This way, we just say “/- consumes all following line-space, and the next “item”, regardless of where you put it (as long as it’s a legal /- location“.

Interestingly, that implies the following are legal too:

node /- //next thing is commented
  foo

node /- /* commented */ foo

I’ll have to adjust the spec prose too, to clarify that these cases are possible.