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
If you find typstyle is not working as expected, you can use // @typstyle off or /* @typstyle off */ to disable the formatter on the next node of code.
However, neither comment style prevents tinymist from applying formatting in certain circumstances.
#iftrue {
// @typstyle offletx= (
"A message that will be split into multiple lines to ensure that each"+" line does not exceed sixty characters in length. This is a common"+" practice to improve readability and maintainability of the code."
)
// @typstyle on
}
Without the if block, the escape hatch works. Inside if, it fails.
Side note: I think splitting operators to their own lines is a "favorable" default behavior compared to merging them into one line when the result would be very long
The text was updated successfully, but these errors were encountered:
In the lastest release version of typst (not updated in tinymist yet), your code is formatted as:
#iftrue {
// @typstyle offletx= (
"A message that will be split into multiple lines to ensure that each"+" line does not exceed sixty characters in length. This is a common"+" practice to improve readability and maintainability of the code."
)
// @typstyle on
}
(Binary chain is here!)
After looking into the case, I found some defects.
Firstly, in your example, the directive // @typstyle off actually applies to the Code in the code block that wraps let. However, we do not check whether formatting Code is disabled, since we mix it into the code block in our process.
It seems that it is not the if expression but the code block that caused this bug.
Secondly, in the code below, the directive takes effect on # instead of the let-binding.
// @typstyle off#letx= ()
Besides, @typstyle on is not a valid directive. We simply check whether the comment contains @typstyle off to decide whether to format the next expression.
Cross-posting as requested from Myriad-Dreamin/tinymist#996
According to the docs:
However, neither comment style prevents tinymist from applying formatting in certain circumstances.
Without the if block, the escape hatch works. Inside if, it fails.
Side note: I think splitting operators to their own lines is a "favorable" default behavior compared to merging them into one line when the result would be very long
The text was updated successfully, but these errors were encountered: