Order of code-lines affects content with given subslide-numbers

[KronosTheLate]

The title only mentions one of the two issues shown below. I though it was the most concrete problem I could put into words. Feel free to edit the title.

Scenario 1: Works as expected

Scenario 2: Removing newline messes up highlighted area

Scenario 3: Highlight on final line leads to no highlighting

Scenario 4: No newline and highlight on final, for completeness

Tagging @OrangeX4 as the author of pinit, which provides the highlighting feature. I am not sure if this bug could be replicated without that package. I have used pinit version 0.1.3, and the master branch of polylux (a few commits ahead of 0.3.1.

[OrangeX4]

This is due to the fact that typst doesn't have a built-in absolute-place, so pinit uses a hack implementation where you need to add a blank line before pinit-highlight.

[KronosTheLate]

I just reproduced this in Touying, so it seems like all effects come from pinit. Is it possible to move this issue over there?

Code used in touying:

``` #import "@preview/touying:0.2.0": * #import "@preview/pinit:0.1.3": * #let s = (s.methods.enable-transparent-cover)(self: s) #let (init, slide, uncover, only, alternatives) = utils.methods(s) #show: init #slide(repeat: 2, self => [ #let (uncover, only, alternatives) = utils.methods(self) #uncover("1-")[#pin(1)Test#pin(2)] #only("2-")[#pinit-highlight(1, 2)] #uncover("2-")[Something new] ]) ```

[OrangeX4]

Like I said, it has nothing to do with polylux or touying, it's caused by typst not having absolute-place, so you need to add more blank lines with pinit :-(

[KronosTheLate]

Right. As it is not a polylux-issue, it is only appropriate to close this.

It also sounds like you, as the author of pinit, is well aware, so I will not make a new issue there.

[OrangeX4]

Maybe I can add a warnning to the pinit readme, thanks for the issue.