Typstyle roadmap 2025

[Enter-tainer]

Typstyle Development Roadmap for 2025

Over the past year, we’ve made significant progress in Typstyle, with most of the major functionalities outlined in #15 now implemented. A heartfelt thank you to all contributors for your invaluable efforts!

Today, Typstyle delivers consistent formatting quality and ensures document integrity, thanks to our robust testing framework. As we look ahead to 2025, our development goals are centered around three key pillars:

1. Reduce No-Format Cases
2. Smarter Formatting
3. Enhanced Pretty Print Engine

---

1. Reduce No-Format Cases

In 2024, we made substantial strides in reducing no-format cases, largely due to the exceptional work of @QuadnucYard. However, formatting is still disabled for certain scenarios, such as markup and math. These limitations are tracked here.

Math:

• bad indent for math equation #132
• Better format for math equation #43
• Correctly handle function calls in math mode #22

Markup:

• Format inline items in text #142

---

2. Smarter Formatting

2024 saw remarkable improvements in table and chain formatting. In 2025, we aim to extend these advancements to more DSLs (Domain-Specific Languages) and leverage tinymist-query to gain deeper semantic insights for enhanced code understanding.

Analysis:

• Avoid breaking DSLs embeded in typst: cetz, tables, fletcher #17
• [ FEATURE ] Format #table in a human readable way #59
• Feature Proposal: Grouped Import Sorting in Typstyle (Similar to Python’s isort) #212
• Treat imported header same as table.header #196

New Features:

• Feature Proposal: Grouped Import Sorting in Typstyle (Similar to Python’s isort) #212
• Feature Proposal: Improved Array Literal Formatting in Typstyle #211

---

3. Better Pretty Print Engine

A more powerful pretty print engine will unlock advanced formatting techniques, further elevating Typstyle’s capabilities.

• Better handling for last arg in function call #95
• Feature request: inline functions with if statements #76

---

We’re excited to continue pushing the boundaries of Typstyle in 2025 and look forward to collaborating with our community to achieve these goals. Thank you for your ongoing support and contributions!

[visserle]

Since I can't find it in the roadmap, would you mind sharing the current status of #104?

[Enter-tainer]

Since I can't find it in the roadmap, would you mind sharing the current status of #104?

No updates on this unfortunately

[QuadnucYard]

Work List

• (markup) Reflow text. feat: wrap text in markup #260 fix: do not soft wrap after labels #281 feat: always break after linebreak syntax and preserve linebreak in more cases in text-wrapping #286 fix: do not always break after \ #291
• (markup & code) Reorder import.
  • Sort import items (in safe cases). feat: reorder import items if no comment or duplication #246 feat: sort import items by default #268
  • Sort import statements.
  • Group imports of the same sources.
• (math) Align by align points. feat: align math by align points #266 feat: calculate column width solely based on the last line of cells in math align #283 feat: never align non-block equations and preserve trailing linebreaks #294
  • Across func call args.
• (code) Align table cells.
• (code) Compact layout
  • last arg of func call. feat: compact layout for args of func_call #261 fix: only enable compact layout when there is only one blocky expr #269 feat: use compact layout for last array/dict arg only when unique #295
  • arrays, dictionaries of single item.
  • call chain.
• (markup & code) Format doc comments as typst source. (blocking: doc syntax, line prefixes)
• (core & dep) better pretty engine. Here we need to use a forked/modified version of pretty.rs.
  • Variable line widths.
  • Indent with tabs.
  • Better union: only ensure the first line is fitted.
  • Line prefixes and suffixes.

[nullzeta]

Should the README point to 2025 roadmap?

typstyle/README.md

Line 184 in a9e3c8b

See the [tracking issue](https://github.com/typstyle-rs/typstyle/issues/15).

Thanks for your work!

[Enter-tainer]

Should the README point to 2025 roadmap?

typstyle/README.md

Line 184 in a9e3c8b

See the tracking issue.
Thanks for your work!

Hi, Thanks for pointing out! Would you mind open a quick PR to fix it?

[nullzeta]

Hi, Thanks for pointing out! Would you mind open a quick PR to fix it?

On this occasion i would like to throw in a few questions if you don't mind ;)
For the context, i am new to github and its rules(principles) for collaboration aren't clear to me yet.

The way i see the right approach to notify a developer about something minor (but not just a typo) like outdated/incorrect info in the docs/readme is to open an issue instead of a PR for the following reasons:

1. Now that one is aware about some "bug", they may want to not just fix it, but also expand on that matter / refactor that part(section).
   • Example: (link to roadmap in readme) A long time passed since 2024 and i thought that now, before updating the readme, you may want to put some additional notes that section. Or, of course, may not.
2. Some "bugs", albeit real, may be known to the developer and they may have a broader vision of the project's future that just makes them leave that "bug" as is and that may be intended.
   • Example: Just happened to me once.
3. Such changes are often super small and require 15 seconds from the developer to fix. But, given 1. and 2., it may be less hassle overall for them to fix it manually if one of "1." / "2." scenarios happens to be the case.

Even when someone's already opened an issue, i've seen developers asking the author to open a PR that adds the mentioned (and maybe discussed in that issue-ticket) fixes. In this particular example it seems even more confusing to me. Is the core intention of that to increase contributions count for the author of that issue or it simplifies the project owner's life somehow?

Tried my best while not being a native speaker so sorry i'm if something sounds confusing.
Thanks :)

I've just realised that my questions are super off-topic but i think i would contribute way more often just be i more confident in how to behave. Perhaps some resource that teaches collaboration in such environments is what i need. Again, sorry and thanks.