You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow, constructing/retrieving and in return providing a different context than the context at which a context block is executed.
Contexts are a rich feature that enable Typst users to do some very cool stuff like relative numbering:
// number headings and figures with the chapter number in the element's context#setheading(numbering: "1.1")
#setfigure(numbering: n=>numbering("1.1", counter(heading).get().first(), n))
// reset figures on each chapter#showheading.where(level: 1): it=> {
pagebreak(weak: true)
counter(figure.where(kind: image)).update(0)
it
}
However, once a package tries to provide an interface similar to the various numbering parameters on elements, it cannot feasibly replicate this behavior in all cases. If the given numbering function would be executed in another context, it would have a possibly incorrect chapter number.
I know that passing around the location of queried elements is rather trivial as this was and still is possible today, but I'm not sure how feasible this is for styles.
Use Case
A translation library that I worked on, but stopped due to the lack of this feature specifically, would incorrectly resolve values incorrectly based on interspersed language styles in queries such as outlines. This is one use case that strictly needs the style part of another context.
#showheading: it=>text.lang#showoutline.entry: it=> {
text.lang// run this within the context of "it"
}
#settext(lang: "de")
#outline()
#settext(lang: "en")
= heading
As mentioned before, providing something like a function as an argument to something takes away the libraries control over which context must be provided. I've been working on a package for subfigures and a problem I ran into is that I can't trivially support chapter relative numbering of references to these figures without using numbering functions, which are in turn evaluated in the wrong context. This is one use case that only requires the location part of the context. I have the location at which I want the numbering function to be evaluated, but I can't tell it to do so.
The text was updated successfully, but these errors were encountered:
Another idea that fits to this issue is to retrieve a value in the context of other elements. Sometimes you need to know the parameters of other elements, outside of their respective scope. This is for example the case when adding space between specific elements. I can image a syntax like context.with(element: par) or something like that.
Description
Allow, constructing/retrieving and in return providing a different context than the context at which a
context
block is executed.Contexts are a rich feature that enable Typst users to do some very cool stuff like relative numbering:
However, once a package tries to provide an interface similar to the various
numbering
parameters on elements, it cannot feasibly replicate this behavior in all cases. If the given numbering function would be executed in another context, it would have a possibly incorrect chapter number.I know that passing around the location of queried elements is rather trivial as this was and still is possible today, but I'm not sure how feasible this is for styles.
Use Case
A translation library that I worked on, but stopped due to the lack of this feature specifically, would incorrectly resolve values incorrectly based on interspersed language styles in queries such as outlines. This is one use case that strictly needs the style part of another context.
As mentioned before, providing something like a function as an argument to something takes away the libraries control over which context must be provided. I've been working on a package for subfigures and a problem I ran into is that I can't trivially support chapter relative numbering of references to these figures without using numbering functions, which are in turn evaluated in the wrong context. This is one use case that only requires the location part of the context. I have the location at which I want the numbering function to be evaluated, but I can't tell it to do so.
The text was updated successfully, but these errors were encountered: