I recently wanted to change the spacing between lines in a document. A quick Google search brought up this SO answer which describes exactly what I wanted: spacing between lines can be set using the leading parameter and spacing between paragraphs can be set with the block’s spacing. Fairly logical once you know how.
However, now I want to style a quote. For example, say I want to simply put the attribution in the middle (I know I could rewrite the quote function with a new show rule - that’s not what I want). How can I find the elements that make up a quote to style them like that. I.e. to change the spacing between paragraphs, I had to set a value for block. What is the equivalent for the attribution and, specifically, how can I find that without having to ask here?
First a quick note: In the next release you won’t have to do show par: set block(...), instead you will be able to do set par(spacing: ...)
You can’t always style things with set rules. For example the quote attribution alignment to the end of the line is hardcoded in the source. So you do need a show rule to build the quote yourself.
As to how you can find out if you need a show rule or not, I also don’t think there’s a general way to do that currently (appart from looking at the source code).
For posterity, @sijo is talking about the next #v0-12-0. In v0-11-1, the syntax is still show par: set block(...). Andrew mentionned the specific PR here.
Ok, I wonder how that could be better documented? Maybe not in this specific case where it’s hard coded, but in the general case. I’ll have a think about it and maybe submit a PR or BR.
Regarding the PR mentioned, thanks! That explains some of the layout changes I encountered after switching to HEAD.
That’s a great question! A lot of people often want to rebuild some element via a show rule to tweak something, but every time you fall into the same pitfall, like you did. I do think that documentation should have a Typst code for recreating every element (if possible). Can you please open a documentation issue?
This change to documentation will probably greatly increase the ease of tinkering for everybody. And you wouldn’t have to keep a backlog of all show rules you created yourself (for future use).
I’ll aim to open a documentation issue, but I don’t like the idea of this having to be done manually every time an element is added or changed. However, for most elements automatically generating a code example is likely impractical, since any combination of arguments would map to any number of completely different results.
Actually, when I said “documented” I was really thinking of something more like VS Code hover function. If I could define a quote in my document, then hover over it to see the equivalent typst code for that particular configuration of the function. Bonus points for a code action to generate the “identity” show function for the element.
Does that sound interesting? Does it sound feasible? I assume this would require generating typst code from an AST. I realise the LSP isn’t provided by typst but I imagine the functionality required to do this would need to be added to the typst-ide crate.
The way elements created internally in Rust isn’t something that changes regularly (you can try git blame and see when those line have been changed the last time). So recreating them manually once per element basically will be a one-time investment. Moreover, making this somehow automated isn’t a trivial task, so I think it is safe to say that this is out of the question for near future (or in general, IDK, I’m not the creator). Also, since normally the function/element related code is documented right above the Rust struct in the doc string, it would be pretty easy to update the show rule code example (for a specific element that had its internal representation changed).
We now can easily access which styles are added to the element, but might not simply reference which exact show rules changes the element. Correct me if I wrongly get the requested feature.
Here@quachpas is talking about a snippet suggestion from the LSP server (could perhaps also be a code action). A snippet includes a show rule for the specific element that can mirror how the element is created in the Rust code. Since tinymist is separate from the Typst itself, it can already start implementing and supporting it. But the caveat here is that not all elements can be fully recreated in Typst right now. And that someone has to manually write such show rules (as close to how it’s defined in Rust as possible). You might want to see the discussion in the created issue for more context.
