Add container attribute to [insert_tag]

[Pentarctagon]

It would be useful for [insert_tag] to have a container attribute, which would, for example, be used as:

[insert_tag]
  name="option"
  variable=var1.var2
  container="var3"
[/insert_tag]

and would then wrap the [option] tag around the var3 of each var2:

var1.var2[0].var3
var1.var2[1].var3
...etc...

rather than currently how:

[insert_tag]
  name="option"
  variable=var1.var2.var3
[/insert_tag]

would wrap the [option] tag around each var3 of var2[0]:

var1.var2.var3[0]
var1.var2.var3[1]
...etc...

[ln-zookeeper]

This seems very confusing and hard to understand, perhaps partially because "container" as the key name sounds rather arbitrary. I can see how sometimes you'd want functionality like that, but how would you even describe it intelligibly in a sentence or two without examples?

[Pentarctagon]

Allows [insert_tag] to wrap the tag provided by name around a common sub-container of each element of the data structure given by variable.

[ln-zookeeper]

Okay... I guess that describes it. But this still seems very difficult to understand and frankly a bit arbitrary. What kind of usecase(s)s do you have for this? [insert_tag] is already a pretty advanced feature, and adding new options like this make it even harder to comprehend,

[Pentarctagon]

My use case at least is that I want to have a data structure, where I want a sub-container of each element of that data structure to contain a list of [option]s that can be displayed.

I'm not sure I understand how [insert_tag] is particularly complex though. It takes a data structure, and wraps a WML tag around each element of it. Adding some additional flexibility to what part of the data structure it uses does not seem like it would add to that.

[CelticMinstrel]

I think the proposed syntax may be confusing. Not sure how to improve it though...

[Pentarctagon]

Maybe something like sub_variable or nested_variable instead?

[sapientN3T]

You are interested in a specific case where each var2 contains a single var3 container, but you seem to have omitted the general case description of what should happen when one or more var2 ("my_wrapper") containers has multiple var3 ("my_option") subcontainers. My assumption is that they would be appended one after the other in the target option. So what you want is a recursive append as an intermediate step.

My gut is telling me: this should be a separate variable manipulation on the variable (or intermediate variable) you wish to insert. "But that's less efficient!" Yeah, but we don't need to streamline the execution time of some extremely specific WML coder's insert_tag use case... especially not by coupling loosely related actions into the same tag (remember how float text functionality was first added to unstore_unit)?

Another idea would be adding the recursive append/merge to set_variables. Then you get rid of your FOR loops, but is it really worth cluttering up the API with some obscure functionality? In my opinion it should be a local WML macro for your own campaign that does a [for] loop and set_variables mode=append (or lua function if you want to get fancy).