Static `ExtraText` and Collapsible `ExtraText` can't be displayed at same time?

[guard-who]

In Task17, Task22 and Task27, we have already set englishVersionHint in a static way, how can we concatenate the collapsible classDiagramFirstHint? The type of addText is ExtraText instead of [ExtraText].

[jvoigtlaender]

Arguably, instead of having

modelling-tasks/example/src/Modelling/CdOd/DifferentNames/Config.hs

Lines 439 to 443 in e46db23

	task2025_repeat_17 :: DifferentNamesConfig
	task2025_repeat_17 = task2025_repeat_15 {
	printSolution = ShowMappingAndReprintCDAndOD,
	extraText = classDiagramFirstHint
	}

this config definition should just be task2025_repeat_17 = task2025_repeat_15 and the printSolution = ShowMappingAndReprintCDAndO and extraText = classDiagramFirstHint should instead be added in https://github.com/fmidue/llm-task-wrappers/blob/9652fd18cefda92ac4dccc0883e146c11637745e/src/Modelling/CdOd/DifferentNamesVariants.hs#L29-L32 as showSolution = ShowMappingAndReprintCDAndOD and addText = classDiagramFirstHint. After all, these are aspects that are really specific for "variant 3", so why not really adding them when differentNamesVariant3 runs?

Then, you can in differentNamesVariant3 decide how to arrange addText = Common.englishVersionHint and addText = classDiagramFirstHint into a single ExtraText. I guess for the moment that would mean to just have either one Static or one Collapsible False with both texts at once.

Down the line, we could think about how to be more flexible with "composable" ExtraText. Basically there are two options:

1. Always having extraText/addText :: [ExtraText] instead of current extraText/addText :: ExtraText.
2. Refactoring https://github.com/fmidue/output-blocks/blob/be840655231dd5118ee66e28de3343628882dce3/output-blocks/src/Control/OutputCapable/Blocks.hs#L663 so that it allows "sequential composition", for example by providing an instance Monoid ExtraText.

I suggest opening an issue in output-blocks.

[guard-who]

After all, these are aspects that are really specific for "variant 3", so why not really adding them when differentNamesVariant3 runs?

I agree with setting them when creating variants. It looks cleaner, but which config version should be set in Autotool? I guess it would be the real one (after changing printSolution and extraText) used for the task, right? If so, we should keep some annotations here to remind us to keep the config records consistent.

I guess for the moment that would mean to just have either one Static or one Collapsible False with both texts at once.

This semester, we might temporarily set them in a single collapsible text and leave the refactoring later.

I suggest opening an issue in output-blocks

Okay, I will do it.

[jvoigtlaender]

I don't think there is a need to synchronize the config on Autotool. At the end of the day, that config will never be looked at again when the instances are uploaded explicitly. So the situation is quite the same as with other instance fields that you overwrite in variant building (e.g. overwriting the task text) and that would never actually be created that way when feeding the config to the Autotool-internal generator.

[jvoigtlaender]

What would make sense, in order to prevent e.g. differentNamesVariant3 accidentally overwriting some addText, to explicitly check, inside differentNamesVariant3, that the current addText is NoExtraText (and otherwise erroring out), and only then set the variant-specific one.