I’m iterating over the children of a sequence, each one can be any type, be it text, math or context. I want to switch depending on the func type like this:
if child.func() == text {
...
} else if child.func() == context {
...
} else if child.func() == space {
...
} else if child.func() in (footnote, box, block, strike) {
...
}
this works totally fine for text, but it doesn’t seem to be working for the rest. probably because these funcs aren’t imported by default(?) or that it’s trying to invoke the function instead of comparing the functions. comparing with string doesn’t work… how do I get these funcs?
when I do repr(child.func) I get this:
text
space
text
frac
context
text
the type of all of the above is content so this doesn’t work. Also the code you provided doesn’t compile, it’s giving the same errors for using context, space, etc I need to get the funcs for these types of content somehow else or compare the repr, which I think may be slow
Usually when you want to do this, you are overcomplicating something. It is rare when you need this, only if you are parsing some user document for your package that work on raw content. So you shouldn’t work with all this unless you are sure that there is no other choice, which depending on your experience, can require another person to know for sure.
There are content functions and basic types, for types you would use type() and for content you would use .func(). Some content functions are not public because you are not supposed to use them. These are styled, context and sequence:
yes, I’m making a package that parses raw content. I managed to do it exactly the way you suggested and have these three as utility variables, and it works well so far.
I’ve ran into a new issue though, apparently it’s not possible to change the body of content manually, and you can’t simply reconstruct it (for example like this: my-content.with(body:my-body)) So what I’m doing right now is so incredibly hacky that it feels like I shouldn’t be doing it. basically I have a method that’s called reconstruct-content where you pass in a template and the new body, and depending on the func type it will call the func and pass in the fields like this:
this works reasonably well, but if I want to replace a nested content (for example highlight(fill:blue)[#text(red)[test]] here I’d like to replace “test”) I will need to do this recursively. show and set rules won’t easily work in my use case, I’ve tried it.
All in all it feels like Typst doesn’t want to be used in the way I’m using it here
For this code block, you need to use typc language identifier, not typ (same with this one, as I’ve already said). Also, when you use code in text, you should use single backticks, otherwise it’s hard to read it. Furthermore, highlight(fill:blue)[text(red)[test]] will output text(red)[test] in blue. See this.
What you are doing is parsing the whole Typst document inside Typst. This won’t work because styles and context do not have a public API to easily work with them and reconstruct them. You can’t do anything with context.
You should create a new Questions topic about what package you want to make. To painlessly (maybe) work with Typst AST, you better just make a Rust Wasm plugin, if you know Rust.
Hi @Ants_Aare_Alamaa, I’ve formatted your code blocks as Andrew has described. I’d ask you to take make sure you format them correctly. I saw that you attempted it; note the difference between typ and typc for a code block’s language.
you may also be interested in this post:
Basically, you need the function and the fields to reconstruct some content, but fields() gives you a dictionary, while the functions take some parameters positionally. That post demonstrates how to do it relatively conveniently.
ah, sorry about the formatting issue, and I meant to add a “#” before the text(red). I was trying to show that I had issues with nested content. And yeah I’m kind of trying to work with the AST inside the package, however smart that may be. I barely got it to work which made me hopeful that there’s an actual way to achieve this. I’ll rethink the current approach though.