On 2020-10-26 at 07:21 -07, Nicolas Goaziou wrote... > Ken Mankoff writes: > >> I question if this is possible because EBNF is for context-free >> grammars, but I *think* Org syntax is context-free. > > It's not as explained in a footnote in the Org syntax document. Yes, I meant to write that I think Org syntax is maybe *not* context-free, and therefore EBNF can't capture all of it. But it could still be very helpful and capture most of it. But the more I think about it, the more I think Org may be context-free. For the footnotes, I'm not sure that "(1) In particular, the parser requires stars at column 0 to be quoted by a comma when they do not define a headline" violates context. An "*" in the first column defines a header. It can be escaped by anything else too (" *" works too). If ",*" has a special meaning, that can be captured elsewhere in the syntax. I'm also not sure (2) violates context-freeness, at least in the EBNF sense where a context can include a newline. See for example: section ::= "*"+ string (tag+) newline (planning newline)? (property_drawer newline)? planning ::= ("SCHEDULED:" "<" date_or_time ">")? ("DEADLINE:" "<" date_or_time ">")? property_drawer ::= ":PROPERTIES:" newline drawer_contents newline ":END:" drawer_contents ::= ":" property ":" whitespace string Where the first line, "section" is represented graphically as the attached image. I guess I'm not 100% clear what "context-free" means. EBNF can represent a language where a for loop has an opening and closing brace. The closing brace is context-dependent, just as the planning or property drawers are. I recently used EBNF to represent a CSV file with header, and I was unable to capture the requirement that the header column must have the same number of fields or commas as the data section. I think that is context-free.