benoitc
Rewrite parser more readable, little faster
@benoitc let me know if you are open to this kind of parser rewrite. Some notes:
- marginal performance improvement, around 10%
- more readable (I think, unless you don't like regex)
- couldn't get multiline values to work in existing implementation, so I left it out (I can add it if needed)
- passes all current tests
- possible further speed improvements with compiled regex
Please let me know your thoughts.
@benoitc thumbs up/down - making things better, or uninteresting? Please let me know when you get a chance.
I completely forgot that change... Sorry for that ... I will look at it now.
more than one year later... Sorry for that... Just if you remember, can you tell me what you meant by couldn't get multiline values to work in existing implementation, so I left it out (I can add it if needed)? Is this something missing in current master ?
@unix1 i guess i see the point. I tested your implementation and it mostly worked. See comments. I know it's a little late to ask, but in case of what was your idea to add support for multilines values?
@benoitc thanks for looking and providing feedback. I'll probably have time to look at this this weekend.
As for multiline values, I remember I couldn't find a standard way of doing it (people do it their own ways when they think they need it, and current master didn't support it) - that's why I didn't put it in. I don't have a use case; unless you have one, I don't think it should be there.
In the hypothetical future where it's needed, we could say:
any config value that ends with a backslash continues on next line:
[letter]
message = Hello,\
This is a message\
Bye
from = Foo
or any non-config non-section non-comment non-empty line:
[letter]
message = Hello,
This is a message
Bye
from = Foo
But it gets ugly fast; and again, unless you have a use case, I'd keep it out for now.