Export `logic.typ` for counter/state access

[ntjess]

It would be nice to provide direct access to the slide counter, subslide, etc. However, since logic.typ isn't exported from the main entrypoint or toolbox, the counters are not accessible.

Toolbox only provides content versions of the first and last slides, and no way to access the current repetitions value

[andreasKroepelin]

What would be the usecase of having access to these states and counters?

[ntjess]

Sure, my preferred slide numbering format is slide.subslide, but this isn't exported by the toolbox. Furthermore, there are more options available when you have the direct number exported, rather than the content-ified version. Therefore I recommend allowing users to access the states, since (IMO) slide/subslide primitives are core presentation concepts rather than implementation details and therefore don't need to be hidden.

A workaround is for users to define their own counter('subslide'), and since the key is recycled they can access the state. But it would be ideal to use polylux's counters directly.

[andreasKroepelin]

Hmm I see. How about having

#toolbox.current-subslide // opaque content

#toolbox.with-subslide(s => 3 + s * 4)

?

Then it's still read-only access (which I would prefer) and at least your use case is covered.

[ntjess]

IMO write access isn't too bad... It can just be clearly stated in the docs that it's undefined/forbidden behavior.

Otherwise, to access multiple properties at once with functions, you have to do

#toolbox.with-slide(s => {
  toolbox.with-subslide(sub => {
    toolbox.with-repeats(r => [
      Slide #s.(#sub of #r)
    ])
  })
})

It seems easier from UX/DX perspective to just provision counter access directly.

Edit: The simple example above works with just content versions of each counter. But having direct access to the numbers allows calculating other ratio/progress values for subslide vs repeats, counting total slides (repeats per slide plus total slides), etc. Typst in general compared to Powerpoint represents infinite customizability, and I'd love for that to continue being the message within polylux for slide fundamentals like numbering.

Edit 2: You could also have a "read-only" counter that's constantly updated by business logic that combines slide + subslide in true counter fashion:

#let slide-subslide = counter("exposed") 
// Handled internally by polylux, so even when user manually overrides the value, it has no effect by the next slide
#slide-subslide.update((1,2))

// User then has more "counter-y" freedoms
#context slide-subslide.display("1a")

[andreasKroepelin]

I think I like your last idea of those derived counters 👍🏼 Feel free to start a PR.

[jounathaen]

In my slide template (which is designed as a wrapper around polylux), there are some slides I don't want to count towards the total number of slides. These are section separators and backup slides. In previous versions of polylux, I implemented this by manipulating the counters in logic.typ.
Now that there is no more access to these counters, I've resorted to implementing my own slide counter. This works just fine and was not too difficult to implement, but now there are basically two counters with the same intention.

[raph-atsec]

As already mentioned, you can access any counter if you know the name.
So counter("logical-slide") gives access anyways, doesn't it void the discussion about access control?

[ntjess]

It works by "abusing" slide implementation details. If the counter name changes, or if/when typst custom elements become possible, this dependence will silently break and be non-obvious how to fix. Hence, this issue is more about making slide numbering a publicly (and therefore at least documented) dependable API