Maurice Makaay 84ae34fb5f Just a bit of code formatting.		2019-05-19 23:44:11 +00:00
..
helpers_test.go	Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.	2019-05-19 23:35:03 +00:00
parser.go	Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.	2019-05-19 23:35:03 +00:00
parser_test.go	Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.	2019-05-19 23:35:03 +00:00
syn_comments.go	Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.	2019-05-19 23:35:03 +00:00
syn_comments_test.go	Ahhhh found a name that clicked for the more general layer of the parser code: parsekit. That is short and tells me what it is. It's not a parser, but something to build parsers with. Now I could also name the actual parsing code as I would like to, namely 'toml/parser'. So it feels like the structure is settling down.	2019-05-17 22:03:10 +00:00
syn_eof.go	More sensible state naming. No need to prefix every state function with state_.	2019-05-18 01:49:30 +00:00
syn_keyvaluepair.go	Just a bit of code formatting.	2019-05-19 23:44:11 +00:00
syn_keyvaluepair_test.go	Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.	2019-05-19 23:35:03 +00:00
syn_strings.go	Just a bit of code formatting.	2019-05-19 23:44:11 +00:00
syn_strings_test.go	Phew, that was quite the update. I've now got a working implementation of a parser/combinator-like matching API, which prevents us from having to specify everything in state functions. That is way too low level for a lot of things. I'd rather have parser/combinator-style definitions for chunks of the input and keeping the state functions for higher level document structure parsing.	2019-05-19 23:35:03 +00:00