Formatter throws away \i, \I

[lucaswerkmeister]

Dammit, that’s some more information that’s not recorded in the AST :-( do I need to add writeToken({String|Token+}) for “could be any of these tokens”?

[lucaswerkmeister]

And of course, this needs to work in the “no token stream” case (#17) as well, which means I have to determine when the \i isn’t optional. But in visitIdentifier I can’t know if it’s used as an uppercase or lowercase identifier, so I’ll probably have to add a global variable for that. Gah.

[lucaswerkmeister]

No, that won’t work either, because the grammar actively removes the \i from the token text. The only difference between \ivar and var is the length of the token.

I suppose I should be glad about that since that means no changes to FormattingWriter, but deciding that based only on the length of the token feels so ugly…

[lucaswerkmeister]

Ah, I’ll still need changes to the FormattingWriter because of fast-forwarding. Oh well…

[lucaswerkmeister]

Uh oh. In an import list there’s no way if a token is supposed to be uppercase or lowercase… I guess I’ll just have to accept losing the information there. (Luckily, an import list seems to be one of the few places – the only? – where that’s okay.)

[lucaswerkmeister]

Dammit. There’s certain imports where the \i is in fact required.

import java.lang {
    System {
        sysin=in
    }
}

I just tried out dogfooding (#29), and this is literally the only syntax error in the resulting code. So close! Gah.

[lucaswerkmeister]

As Gavin demonstrated in ceylon/ceylon-ide-eclipse@a738953, it’s actually perfectly possible to get all that information from the token, so I don’t need to do any guesswork, and can get rid of visitIdentifier{Uppercase,Lowercase}. Phew…