Open GoogleCodeExporter opened 9 years ago
I ran into this problem too. Really great library, but this just looks bad:
skycolor:
- 1
- 1
- 0
entities:
- mesh: Racer
position:
- 120
- 100
- 100
rotationPYR:
- 0
- -0
- 0
- mesh: Tribune
position:
- 50
- 12.8
- 150
versus (written manually):
skycolor: [ - 1,- 1,- 0]
entities:
- mesh: Racer
position: [- 120,- 100,- 100]
rotationPYR: [- 0,-0,0]
- mesh: Tribune
position: [50,12.8,150]
Original comment by werner.k...@gmail.com
on 4 Oct 2013 at 9:46
My company has been using yaml-cpp and extended it to set an emitter style on
the node. I have posted this change to my github account [1], and have attached
a patch here.
[1]
https://github.com/paulnovo/yaml-cpp/commit/b975833ee6c71159dd2189b772feb16e4222
818a
Original comment by pnovo...@simquest.com
on 20 Feb 2014 at 9:07
Attachments:
Issue 250 has been merged into this issue.
Original comment by jbe...@gmail.com
on 8 Jun 2014 at 12:25
Awesome. Will any other node flags be needed in the for seeable future, or is
this the only one?
Original comment by ARandomFurry
on 8 Jun 2014 at 4:57
I'm not sure - I think precision would be reasonable too.
Original comment by jbe...@gmail.com
on 8 Jun 2014 at 5:04
How about a flag to explicitly show what the value is (ie: force appending .0
for non-integer numbers [or prepending 0.?], as well as wrapping a string in
quotes, even if it is one word, etc)?
Original comment by ARandomFurry
on 8 Jun 2014 at 7:42
Explicit quoting sounds good. Not sure about the other bit.
Original comment by jbe...@gmail.com
on 8 Jun 2014 at 7:46
This ties into another one of my posted issues/request/w.e about how to
determine what type a value is. Having explicit formatting for integers/decimal
numbers/strings allows polymorphic entries in the YAML file without the need to
include another value denoting the type.
Original comment by ARandomFurry
on 9 Jun 2014 at 3:34
I added setting block/flow styles in ra5b90577e0807370cd426a58983a16a759bc1ebf
(merged from pnovotny's patch, thanks!)
This is sort of a trial API. Since I'm not sure what the plan will be for other
styles, I'm going to leave this issue open and lower the priority, and leave it
for discussion about what sort of other styles should be set.
If we end up with something a bit more general, I may tweak the SetStyle API,
so be prepared for that to change (I marked it with a warning in the source).
Original comment by jbe...@gmail.com
on 24 Jan 2015 at 7:35
Original comment by jbe...@gmail.com
on 24 Jan 2015 at 9:26
Explicit quotations would be great.
Original comment by JaminThe...@gmail.com
on 26 Feb 2015 at 11:18
Original issue reported on code.google.com by
jbe...@gmail.com
on 15 Jan 2013 at 5:32