Parse attributes of a component

[vshesh]

For AnnotatedCode, if you make a comment like:

def f(x):
  # comment with *bold text*
  if x: return True
  else: return False

You will get the string comment with *bold text* in the annotation, without it being parsed.
I'm not even sure how we would parse the annotated comment in this case, but it does look strange, and ideally it would be nice to be able to include at least inline styles (eg, links especially) in the comments.

One option is to manually parse the string in the annotation inside the annotatedcode component. That would probably be the easiest to implement, but the question is - where does the registry come from?
So now every parser function has to be passed the registry it's being parsed from? That's madness, and suddenly its making things a lot more complicated than they need to be.

Another way is to "mark" an attribute as needing further parsing. This is also silly because it complicates the return value of the parser functions in situations where it's not needed, but it keeps an ugly circular dependency from happening...

A further question is what do we do with the parsed value - how does that get propagated up to the component in the view?

One more option is to let the view component handle it in the frontend, but now we're dealing with extra requests to the backend. Also, it's not possible to compile the file and just serve it - there would have to be an endpoint constantly compiling these strings.

The last option is to setup components so that these "sub-parsing" things are children of the component.
Eg: annotated-code has children which look like ['annotation', {line: 1}, 'annotation text']
these will get automatically picked up by the parser and we will end up with something that looks like a template.

A question of convention - should these children be {tag, attrs, body} type things in the AST or {name, props, children}? My tendency is towards the latter, in which case I should be returning ['Annotation', {line: 1}, 'annotation text']` instead.

[vshesh]

if the latter approach is taken - how to distinguish a subcomponent as a child that needs its own processing from a child that is just data?
perhaps {tag, attrs, body} is the way to go... or I can come up with another format, but that seems like overkill.