Ticket #114 (new enhancement)

Opened 9 years ago

Last modified 5 years ago

Comments in the emitter

Reported by: pistacchio@… Owned by: xi
Priority: low Component: pyyaml
Severity: normal Keywords:
Cc: pc@…


Hi, i think there should be a way to map comments so that they can me emitted. AFAIK, at the moment there's no way to dump:

# This is a section comment
-   home: 'something'
    name: '1'
-   home: 'something else'
    name: '1'
# Other section
-   home: 'again'

Change History

comment:1 Changed 9 years ago by cce

It's sort of difficult unless you provided some sort of path expression to comment mapping, or had some other way to adorn the items in the list with comments. Comments are out-of-band information that really were not intended to be round-tripped. I think this request would need some operational suggestions before it could gain much traction.

comment:2 Changed 9 years ago by anonymous

It could be inserted into the yaml object, just like tags. Something like yaml_comment.

comment:3 Changed 8 years ago by anonymous

This would be a great addition to libyaml.

comment:4 Changed 8 years ago by pschmitt@…

This would be very helpful for my work: I use PyYAML to dump the current settings of my program just before exiting cleanly.

Many of these settings (e.g. {"background-color": "blue"}) are self-describing and the user should have no problem figuring out what to change, but I would love to add some #comments to describe some more cryptic settings.

In the meantime, my solution is to add a nested "help" dictionary explaining what a particular setting is.

comment:5 Changed 7 years ago by anonymous

Another useful case would be to preserve the comments that exist in the file through load->edit->dump cycle. Presently, all the comments that existed in the original file are lost.

comment:6 Changed 7 years ago by abe.music@…

For a project I'm working on it would also be useful to keep comments intact. We are taking a template configuration file, modifying it, and pushing the file out to several servers. Like one commenter, our parameters are self-documenting, but having inline documentation to state what the intended use or optional values are would be very nice. Instead they would have to come back to check our wiki or documentation. It would be much easier/better for them to read the comments directly in the file.

comment:7 Changed 7 years ago by pc

  • Cc pc@… added

I'm also has a project where comments would be useful. I think it should be field in yaml_event_t. Comments should also be presented at the same level of indentation as data and probably should be rewrapped just like folded scalar (or it should be customizable?)

Another way of implementing that would be to add just another event for comment, but I see it as incompatible with current implementation and not friendly to a parser (if we will implement preserving comments in parser).

If I will provide a patch for libyaml, are maintainers willing to accept this kind of stuff?

comment:8 Changed 6 years ago by anonymous

I was in the process of writing a custom format to get around some of the limitations of json, when I came across YAML. It seems to have it all, apart from preserving comments, which is is an essential feature for our use. I understand it's fairly low priority, just wanted to know what the chances are of it being implemented, and how soon?

comment:9 Changed 6 years ago by anonymous

+1 for preserving comments. I use yaml for config files and it would be great to hint users about the available options to the various params.

comment:10 Changed 6 years ago by anonymous

A must have to edit configuration files.

comment:11 Changed 5 years ago by anonymous

  • Severity changed from minor to normal

Not preserving comments in round trip load/dump cycles fundamentally alters the original file. This *needs* to be added, bumping the severity as there doesn't seem to be any progress here.

Note: See TracTickets for help on using tickets.