QuadnucYard
QuadnucYard
What's your idea about range specification (both API and CLI)? A straight forward choice is to specify character offsets (in byte) only, but it is not friendly to CLI users....
Some questions about the implementation. Take a piece of code from indenta as example: ```typ #let fix-indent(unsafe: false)={ return it=>{ let _is_block(e,fn)=fn==heading or (fn==math.equation and e.block) or (fn==raw and e.has("block")...
And what's your idea about testing? I think a few (
> for 1 and 2, we can simplify the problem in the initial implementation. we can assume that user will only select a full line. this is "format changed lines"...
## Range specification and error handling We may specify a byte range or a row-column range. In a row-column range, we may omit the column. There are some errors: -...
When there is a syntax error, it could be meaningless to return the original text as the format result. For formatting in place in CLI, we can just do nothing...
It is sensible to describe the range by unicode char index (from 1) instead of byte index, which is consistent with VS Code and other formatters mentioned before. In this...
I think this has been resolved by #153, #154, #167.
Hello! This has been solved to some extent in v0.12.2 by #149. Now it won't enforce multiline-styled code blocks unless the line is too long or you intend to do...
We still need to make the inline/block style of all branches of an `if` expression consistent before finally closing this issue.