QEDK
Comments are discarded
Hi 👋. I'd like for the config parser to be fully idempotent meaning when I parse a config and immediately write it out again, I'd expect to get the same exact document (with the possible exception of whitespace). Right now, however, comments are ignored so when I read in a config file, make a change, and write it out again, those comments are lost.
@rylev The parser as it currently is, simply strips out anything in comments, empty lines and all of that - making a pure hash table, to put it simply, it doesn't remember where is what (and that is also inefficient). There can be multiple ways to have this idempotency with complete idempotency being the most difficult and less use than the work involved (imho). When you say comments, what type of comments do you usually use?
I totally get why this is not the default behavior. This is really just useful in the case of wanting to adopt an existing ini file. We're using ; comments across the entire file. In general it looks something like this:
;
; Comments
; comments
; Comments
[Section1]
MYKEY#ServerName=Server01
; Some comments
[Section2]
; Comments
Key_I_Want=server01,server2
I totally get why this is not the default behavior. This is really just useful in the case of wanting to adopt an existing ini file. We're using
;comments across the entire file. In general it looks something like this:; ; Comments ; comments ; Comments [Section1] MYKEY#ServerName=Server01 ; Some comments [Section2] ; Comments Key_I_Want=server01,server2
I think completely idempotency is not ideal - simply because it will require a whole separate API, for the parser atleast. At the moment, I'm considering partial idempotency, in the form where we retain comments and their formatting and store them in a separate hashtable - but the current scenario of discarding anything after a comment line would still be the case, so that would mean:
; comments <--- valid, formatting retained
MYKEY#comments=server01 <--- invalid, MYKEY stored as empty key and everything after # is a comment
The sad part is that Rust does not allow variable parameterization, so a new parser would have to be made and made to be interoperable, which is some work... but it is feasible.
The final question is that of utilization, how more difficult is understanding ;comments and ; comments - is there any scenario where it's absolutely required?
Hi, do you still have plans to add in the support for preserving comments as mentioned in your reply?
If you're not doing this at the moment would you be happy for me to look into it with a view to submitting a pull request for you to have a look through?
