I might sooner or later want to rewrite FormattingWriter, in order to simplify and clean it up, and to profit from my (hopefully) increased skill both generally and in Ceylon (cf. 012ba382e60903aeefc899ad7f23861a986b3178). Here’s what I want to do then:
[x] Separate direction and stacking of indentation.
Currently, all indentAfter stacks, and all indentBefore doesn’t stack. However, I came across cases where I wanted an indentBefore to stack, at least a bit, or where I didn’t want an indentAfter to stack after all. We’re better off with separate parameters indentBefore, indentAfter: Integer and stackIndentBefore, stackIndentAfter: Boolean. Done in 5563ef0619811e42c971b6c4a16e07f13cb18ca7.
[ ] Consider renaming indentBefore and indentAfter back to preIndent and postIndent.
The history of the writeToken parameters is somewhat convoluted (I’m pleased that past me wrote really nice and long commit messages; enjoy 3efec055569fa17bb10dd286284e757e3ee91272, 7a6fdbdd34c9bfa165e1d41aad757653f10e852a, 0d8e82e6e0559b642fb4ad34e1061bdc546d86d2 and c71dd4bd3bcb26739c3c9e38b594b3d4ea84b0b0), but the result is that I still find myself thinking about preIndent and postIndent rather than their actual names indentBefore and indentAfter. They’re probably better: shorter, roll easier off the tongue, and really, “pre-” and “post-” isn’t as “cryptic” as I dubbed it in 3efec055569fa17bb10dd286284e757e3ee91272.
[ ] Consider more carefully what needs to be shared and what doesn’t.
Currently, we share some quite internal classes of FormattingWriter, just so they can be used by DefaultLineBreaks. Perhaps with some more thinking, the part we need to share can be restrained to less internal stuff.
Of course, an alternative would be to abandon the notion of different line break strategies altogether, and make the one we have internal too.
[x] Make stackability of indentation ternary
Currently, indentation of a token either stacks or doesn’t stack (partially depending on the direction – see above). I think that in rare cases, including #105, we’ll need a third possibility: indentation stacks if and only if it’s actually applied, i. e., if the token is the last (postIndent) or first (preIndent) of its line. Done in 5563ef0619811e42c971b6c4a16e07f13cb18ca7.
[ ] Allow opening and closing contexts simultaneously
Currently, writeToken returns a new context iff the token didn’t close an old context. I don’t think I’ve ever actually needed to simultaneously close and open a context – this assumption has held up quite well – but it’s a potential trap (what happens when you provide a context to close, and also some postIndent? I have no idea, I’d have to try it out, but neither “drop postIndent” nor “return a context” is good), and it’s annoying that the typechecker doesn’t know when writeToken will be guaranteed to return a non-null context, so you occasionally have to assert the existence of the context because closeContext doesn’t accept null.
This means we’ll have a few extra unneeded contexts lying around, but I don’t expect that to make any difference in performance.
I might sooner or later want to rewrite
FormattingWriter, in order to simplify and clean it up, and to profit from my (hopefully) increased skill both generally and in Ceylon (cf. 012ba382e60903aeefc899ad7f23861a986b3178). Here’s what I want to do then:[x] Separate direction and stacking of indentation.
Currently, all
indentAfterstacks, and allindentBeforedoesn’t stack. However, I came across cases where I wanted anindentBeforeto stack, at least a bit, or where I didn’t want anindentAfterto stack after all. We’re better off with separate parametersindentBefore, indentAfter: IntegerandstackIndentBefore, stackIndentAfter: Boolean. Done in 5563ef0619811e42c971b6c4a16e07f13cb18ca7.[ ] Consider renaming
indentBeforeandindentAfterback topreIndentandpostIndent.The history of the
writeTokenparameters is somewhat convoluted (I’m pleased that past me wrote really nice and long commit messages; enjoy 3efec055569fa17bb10dd286284e757e3ee91272, 7a6fdbdd34c9bfa165e1d41aad757653f10e852a, 0d8e82e6e0559b642fb4ad34e1061bdc546d86d2 and c71dd4bd3bcb26739c3c9e38b594b3d4ea84b0b0), but the result is that I still find myself thinking aboutpreIndentandpostIndentrather than their actual namesindentBeforeandindentAfter. They’re probably better: shorter, roll easier off the tongue, and really, “pre-” and “post-” isn’t as “cryptic” as I dubbed it in 3efec055569fa17bb10dd286284e757e3ee91272.[ ] Consider more carefully what needs to be
sharedand what doesn’t.Currently, we share some quite internal classes of
FormattingWriter, just so they can be used byDefaultLineBreaks. Perhaps with some more thinking, the part we need to share can be restrained to less internal stuff.Of course, an alternative would be to abandon the notion of different line break strategies altogether, and make the one we have internal too.
[x] Make stackability of indentation ternary
Currently, indentation of a token either stacks or doesn’t stack (partially depending on the direction – see above). I think that in rare cases, including #105, we’ll need a third possibility: indentation stacks if and only if it’s actually applied, i. e., if the token is the last (
postIndent) or first (preIndent) of its line. Done in 5563ef0619811e42c971b6c4a16e07f13cb18ca7.[ ] Allow opening and closing contexts simultaneously
Currently,
writeTokenreturns a new context iff the token didn’t close an old context. I don’t think I’ve ever actually needed to simultaneously close and open a context – this assumption has held up quite well – but it’s a potential trap (what happens when you provide a context to close, and also somepostIndent? I have no idea, I’d have to try it out, but neither “droppostIndent” nor “return a context” is good), and it’s annoying that the typechecker doesn’t know whenwriteTokenwill be guaranteed to return a non-nullcontext, so you occasionally have toassertthe existence of the context becausecloseContextdoesn’t acceptnull.This means we’ll have a few extra unneeded contexts lying around, but I don’t expect that to make any difference in performance.