Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slide Abort #23

Open
psionic-k opened this issue Dec 10, 2024 · 0 comments
Open

Slide Abort #23

psionic-k opened this issue Dec 10, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@psionic-k
Copy link
Member

psionic-k commented Dec 10, 2024

Slides need the capability to decide if they will decline to process further steps. A babel init block should be able to decide to reject an entire slide and the slide should never even be visible.

This abort check would propagate up through parents. Slide actions and the deck can just move on to their next children. For actions with multiple or inline children, the result would be similar to if they filtered the slide.

In the same dynamically scoped filthy way we do other slide communication, a state will be checked. Calling dslide-abort within a babel slide should be enough.

So what state should be found? Slide objects don't always exists. Markers to headings on the other hand are robust enough to use this way.

In a single step, multiple rejections could occur. Each call to dslide-abort would push an element of a list. Parents would check this list and decide if they handle it or not, like error propagation.

Like any exception system, we need types. The format for abort could be something like (EPOM TYPE REASON) and any action or the deck can interpret and recover how it wants. EPOM is element, point, or marker. TYPE is a symbol or list of symbols for upstream callers to decide reactions on. REASON is for warning / erroring informatively.

There is no way to discover if a slide will abort without instantiating it, so the only way to do such a check for the contents screen is to make the abort decision in the init blocks of a presentation, if these are supported.

Aborting any child from any parent should be possible. The abort stack would be pushed when going into children and popped when coming back to parents. This fits the original design goal of stateful sequences. The parent state always lives longer than the child. The deck is the highest parent.

@psionic-k psionic-k added the enhancement New feature or request label Dec 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant