-
Notifications
You must be signed in to change notification settings - Fork 35
Syntax Highlighting #207
Comments
This feels like it should live in a separate repository to me, or rather two repositories; one for syntax highlighting and one for the diff logic. Do we want them to live in the I feel like pretty-printing elm source code, including syntax highlighting, is a task that has very little to do with https://github.com/Bogdanp/elm-ast seems to have the ast parsing part done, so this sounds like a fun little project to do. |
@drathier The syntax-highlight is already done in a separate repository. Are you saying the output should live in a different repository, like elm-test-cli-output? |
@pablohirafuji I was thinking that it's a good idea to separate the syntax tree that says what color everything should be from the output, so cli and html runners can encode the colors using css/ansi/whatever. I really shouldn't be commenting on stuff like this when I have a fever. I'm sure you know what you're doing, so just carry on. I'd love some syntax highlight in the runners. |
@drathier I am sorry if I sound a bit too harsh. English is not my main language, so the tone may not express my real intent. Sometimes I have to confirm what I read to check if I really understood the meaning. I would love to help make it happen! I am a newcomer here, so I don't have any opinion on the separate repository thing, but I would like to help with the syntax highlighting :) |
I did a toConsole function in the SyntaxHighlight package. Hope it helps! |
@pablohirafuji's
elm-syntax-highlight
means test runners can display syntax-highlighted output! Even better, this also means that really long records can finally be outputted in a multiline format for readability, even thoughtoString
outputs them as single-line.I'd like to run the syntax highlighter on the output of
getFailureReason
, and transform the tokenized output into something ready for the test runners to consume.Obviously different runners will want to translate the syntax highlights into different outputs. For example, the CLI would emit ANSI character codes to change colors and such, whereas the HTML runner would use CSS to style them.
Based on this, I think parsing things, inspecting the tokens, and then handing off a nicely formatted (in terms of line breaks) syntax highlight data structure to the runners makes the most sense. The runners can take care of translating that into actual colors. (It'll be tricky finding colors for the CLI runner which look good on both light and dark terminal themes, which I don't think we can detect, but we'll figure something out.)
I'd also like to modify
Reason
to add a tag for HTML test failures (fromeeue56/elm-html-test
), which we can syntax highlight usingSyntaxHighlight.xml
rather thanSyntaxHighlight.elm
.I think it makes sense to do this in
elm-community/elm-test
rather than in each individual runner because that way we can have consistent syntax highlighting and line breaks across runners. (I could also see an argument for moving the abstract diffing logic from rtfeldman/node-test-runner#206 into here for the same reason.)The text was updated successfully, but these errors were encountered: