Closed belak closed 4 months ago
I see the failing tests - currently working on fixing those (looks like I broke multiline handling).
Should be good to go now!
Why is this needed @belak? Seems to be redundant with comment prefixes, we are not really aiming for API parity with Python configparser
.
Why is this needed @belak? Seems to be redundant with comment prefixes, we are not really aiming for API parity with Python
configparser
.
Good question. In our config files, we currently allow full-line comments but no inline comments, which allows us have comments, but allow usage of ;
and #
in config values.
This PR allows us to get this behavior by setting inline_comment_symbols
to Some(vec![])
, disabling inline comments but allowing full-line comments to continue working.
Another option which would work for us would be a way to only disable inline comments, but I went with this option because it's a way of accomplishing it with the added bonus of improving parity with the Python configparser.
I would love to have this option as well. I currently have to disable '#' comments in the parser and preprocess the string to remove '#' line comments because the .ini I've been supplied with also uses '#' in some section headers...
Thanks for merging this!
Thanks for merging this!
Thanks for the contribution!
This adds an option to set inline comment separators separate from the comment separators, similar to the inline_comment_prefixes in the Customizing Parser Behavior section of the Python library docs.
Notes:
Option<Vec<char>>
was used to keep the current behavior as the default - updating the comment separators will carry over to the inline comment separators if inline is not set. This allows it to be made as a backwards compatible change.