I'm not sure I understand your resistance to putting things in the model. Maybe you can think about it this way:
Would you like to be able to do the same kind of insertion in the console or in another controller, like:
some_model.set_text("{{foo}}")
The it should most likely be on the model.
Um, the thing is that the model will have to "analyze" the data between brackets.
Yes, that's what model's do, they "analyze" or in other ways handle data. Some might even say, that the model _is_ the data. The controller is simply a way of manipulating the model.
What if tomorrow I change the annotation way and there is no more text in brackets, but...I dunno...selecting checkboxes? Has the model to manage the changes in the app View? has to be aware if the annotations are coming to it in form of text in brackets or in checkboxes?
If you are really doing the same thing you could either update the model to account for an alternative way of setting the same attribute or you could make the controller convert the checkbox input into a string for your model, though I would probably go for the former in most cases.
The model must be agnostic. It should accept (require) a specific type of input and your views / controllers should respect that format. This allows you to keep your code simple.
User.new() accepts a hash. It just so happens that Rails takes parameters from a view and stores them as a hash.
I believe this is called “programming to an interface.” That said, Ruby does make it more interesting by allowing you to determine what was passed into the method,.