Global state is modified when things are added to the input queue, not when they're removed

[davidchisnall]

Moving to an issue from this discussion, since I think this affects other people, it's just harder to reproduce (and possibly hidden by other things).

The folio package is the one where I saw this, but it probably isn't the only one.

The commands in this package called with registerCommand callbacks modify some global state to track the state of a page. This is not synchronised with a page though. These commands are executed when the typesetter adds things to its output queue, but then consumed when the typesetter removes some things from the output queue. There is no requirement that the typesetter consumes the entire output queue and so this global state can become out of sync.

Ideally, there would be a hook that you could use to register a callback on the currently-being-assembled vbox, which would then be called when the vbox is popped from the output queue.

[Omikhleia]

We'd need an MWE that shows an actual problem.
(I've never had issues with the folio package so far, the state is used when the page is shipped out, which seems legit to me)

[davidchisnall]

The state is used when the page is shipped out, but it's updated when the \nofoliothispage command is added to the output queue. The typesetter does not always consume the entire input queue to build a page (page builder can consume up to all of it, but doesn't have to if that would be overfull). It's easy to trigger with my toyfloats package (I've just added a hack that works around it by not trying to add more things to the queue if the last thing is a big penalty) but there are almost certainly corner cases where it will happen if there's something that calls \nofoliothispage or \folios in an element that's added to the output queue but not consumed by the page builder.

[Omikhleia]

nofoliothispage command is added to the input queue.

It's not added to the input queue. (There's no such things, there's a nodes queue before shaping and paragraphing occurs, and an output queue, for each typesetter used).
If it's easy, can you trigger an observable issue with only the regular page builder and the standard book class? Even if a hook is eventually needed for some weird case, we'd need a regression test case (for reproduction etc.) = so the MVE is needed anyway.

[davidchisnall]

It's not added to the input queue. (There's no such things, there's a nodes queue before shaping and paragraphing occurs, and an output queue, for each typesetter used).

Sorry, typo. That should have read output queue.

If it's easy, can you trigger an observable issue with only the regular page builder and the standard book class? Even if a hook is eventually needed for some weird case, we'd need a regression test case (for reproduction etc.) = so the MVE is needed anyway.

I'm not sure I can come up with a case that will trigger it. A \nofolios followed by a vbox that is so big that it ends up on the next page and contains a \folios would, I think, except that the current typesetter favours overfull pages and so I'm not sure how to build such a vbox to guarantee that it actually ends up on the next page.

[Omikhleia]

... a vbox that is so big that it ends up on the next page and contains a \folios

A vbox never contains a \folios... There's some misunderstanding here.