Comments

[allanjude]

Comments are lost when the UCL is emitted as UCL

In the case of a tool that reads a config file, applies edits, and writes the config file out again, this is a fairly large issue.

Keeping the positioning of the comments may be quite challenging

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[vstakhov]

We've discussed that with @bapt some time ago. But we've not concluded anything. I'd say that this feature is possible to be implemented, however, in terms of optimization it is not. Thought, I'm still open for suggestions. I have two possible choices:

• Attach comments to the nearby objects (but which ones: laying before or after?) using fields in the trash_stack
• Save comments as a specific UCL objects

[allanjude]

Originally I was thinking of saving them as UCL_COMMENT which would be a string, and in the case where the comment is 'inline' after a regular object (rather than on its own line), to insert it before the object it is sharing the line with.

However, if it goes on the track_stack, it would seem to make sense to attach it to the object that comes after the comment.

In most cases comments either look like:

My comment about foo=bar

foo = bar

or

foo = bar /* my comment about this */

So in case A (trash stack), it should be acceptable to canonicalize the comments to be after the object. So both of the above cases would turn into the latter.

In case B (comments are their own objects), it should be acceptable to have the comment come before the object, like the first example.

[allanjude]

Bapt@ proposed an interesting idea

Along with whereever we store the comment (in track_stack or as its own type), including a parameter that tracks where the comment was positioned.

above

/* before */ foo = bar # after

or something like that, to preserve the location, rather than canonicalizing it

[allanjude]

Initial support for comments (as separate objects) was added in 51dad15b6878abadbe8e3621d16f4f1e9dc22838