Closed GoogleCodeExporter closed 8 years ago
This is a nice idea, but I'm not sure how it would be presented in the API. For
example,
- foo
# a comment
- bar
To which node should we attach the comment?
Perhaps it would have to be in the event API (which isn't public, yet), and
then if you wanted them, you could handle that as well.
Or, do you simply want comments to be preserved so that when you output an
already-parsed document, it prints the comments you started with?
Original comment by jbe...@gmail.com
on 10 Mar 2012 at 12:44
I'd attach it to foo, I suppose.. so long as it's something consistent.
preserving the comments is the most important (I don't want to be losing data
in the files I edit) but the ability to edit comments too would be useful.
Original comment by chan...@gmail.com
on 10 Mar 2012 at 1:26
I see, makes sense.
I'll mark this as "accepted", but it's a relatively large undertaking, so I'm
not sure when I'll get to it.
Original comment by jbe...@gmail.com
on 10 Mar 2012 at 6:08
thanks :)
the code looks readable, so maybe I could take a stab at it sometime.. we'll
see... I need to get my basic node reading & writing done first of course :)
Original comment by chan...@gmail.com
on 10 Mar 2012 at 7:45
Interesting, because I needed this too (though I use Ruby mostly, not C++).
It has really annoyed me that even my top-only comments, which explain what
this yaml file is good for, are gone when I use yaml (in Ruby though).
Just a general comment about # comments. :)
Original comment by sheve...@gmail.com
on 8 May 2012 at 10:03
@shevegen, thanks for your input!
Original comment by jbe...@gmail.com
on 12 May 2012 at 12:43
Original comment by jbe...@gmail.com
on 19 May 2012 at 9:10
I need this for C++ AND for separately for Python.
There are requests for this feature on almost all the various Yaml packages'
issue tracking. And the reason is simple - there are a lot of people who have
human-edited configuration files, perhaps with comments, and wish to preserve
those comments through (light) editing.
If you had this feature (and fixed its streaming issue 154, but everyone else
seems to have a similar issue! :-D), yaml-cpp would be the "best of breed" for
Yaml parsers.
I agree that it's not 100% clear in *all* cases which comment is attached to
which component - but it is in most and simply arbitrarily deciding and
documenting for edge cases would be perfectly fine, users would soon learn.
This would be a very useful feature for me and I'd be willing to devote some
time over the next few months to helping make sure this got done.
Here's how IMHO to proceed.
0. Set up some limited mailing list or just a CC list of people who were
interested.
1. Decide on the comment association rules - "which Yaml element is this
comment associated with?"
2. Decide abstractly (through discussion) where we are going to put the
comments in the API - they'll have to be "optional" somehow for backward
compatibility.
3. Actually change the API to have these fields, without actually implementing
them.
4. Implement the reading and writing parts bit at a time.
5. Profit!
Feel free to contact me at tom (at) swirly dot com.
Original comment by tom.ritc...@gmail.com
on 14 Apr 2013 at 11:44
Two more things occurred to me.
The first is that you could keep extra whitespace with the comments. No reason
not to, and then the program could do "round trips" - i.e. where you convert
from Yaml and then back and have a file that was byte for byte identical.
Regarding the comment association rules, it seems to me that if we simply say
that the comment is always attached to the thing "right before it", there's
always only one way to do it, and that way is nearly always the intuitive
solution too. In other words, we move backward to find the smallest complete
thing, and attach the comment to that.
And this results also in a neat algorithm! When you get to the end of a token,
you just sweep up all the whitespace and carriage returns and comments,
everything after it until the next token, and attach them to the address of the
first token - and then when it comes time to emit that token, you just drop
this all out again "as is".
Easy to implement, but also really easy to explain to users...!
Original comment by tom.ritc...@gmail.com
on 15 Apr 2013 at 4:22
Don't all rush up at once! :-)
I have some spare time in May so if nothing comes of this, I might fork the
repo and make the change. This is not a guarantee, however...
Original comment by tom.ritc...@gmail.com
on 19 Apr 2013 at 6:06
Sorry, I've been away for a bit.
I'll consider this, but I don't think I want to offer perfect in/out round
trips. I don't want yaml-cpp to output nasty YAML. But I do see value in
keeping comments, so I'll think about it.
Original comment by jbe...@gmail.com
on 3 May 2013 at 1:09
[deleted comment]
This issue has moved to github: https://github.com/jbeder/yaml-cpp/issues/154
Original comment by jbe...@gmail.com
on 30 Mar 2015 at 1:28
Original comment by jbe...@gmail.com
on 30 Mar 2015 at 1:29
Original issue reported on code.google.com by
chan...@gmail.com
on 9 Mar 2012 at 10:58