Feature request: highlighting

[ccapndave]

Hey! I've been using your plugin a lot and absolutely love it; wiring up Cmd-S to elm linting makes a great environment to work in! One request that I have, if at all possible, is to somehow highlight the bits that are in yellow in the Elm output that highlight exactly where the error is. Quite often I find that I have to go to the console for long error messages to find out which bit is really throwing the error.

If its complicated to embed colours in Lighttable then even putting some other easily spotted indicator like the @ symbol around the offending item would be fine, e.g.

The type annotation for `view` does not match its definition.
The type annotation is saying:

    Signal.Address Action
    -> { students :
             List
                 { name : String
                 , pouchAttachments :
                       Maybe
                           { photo : { content_type : String, data : String } }
                 , pouchId : Maybe String
                 , pouchRev : Maybe String
                 }
    , units : List Unit.Unit
    }
    -> { ..., currentlyEditingStudent : @@ Maybe Student.Student @@ }
    -> Html

But I am inferring that the definition has this type:

    Signal.Address Action
    -> { students :
             List
                 { name : String
                 , pouchAttachments :
                       Maybe
                           { photo : { content_type : String, data : String } }
                 , pouchId : Maybe String
                 , pouchRev : Maybe String
                 }
    , units : List Unit.Unit
    }
    -> { ..., currentlyEditingStudent : @@ Editable @@ }
    -> Html

[rundis]

I've looked into this, and the problem is not really related to Light Table as such. I'm getting a json back from elm-make, and what is shown as inline messages is an overview field and a details field from that Json. These are just text fields (but with formatting in terms of newlines and tabs/spaces, that's why the output looks fairly ok)

For me to replicate the coloring used in the system.out format from elm-make I would either need very detailed parsing of the text (with mapping to the format used by elm-make for all kinds of scenarios;records, params) or I need to partially parse and then apply some diffing algorithm for what is recognized as expected/actual pairs. The first alternative would be extremely brittle I think, the second might be less brittle but not exactly trivial to implement.

I'm open to suggestions, ideally something with a sensible cost (as in time)/benefit ratio ! (I think that to do this properly the json report from elm-make would need to provide a lot more details)

In the meantime I can let you know that I'm working on improving the display of lint errors in general (marking code ranges for warnings/errors to give the messages more context, and also introduces the ability to show multiple errors/warnings per line, keyboard shortcuts for moving to next/previous lint result etc). I might even throw in the possibility to do "quick fixes" for a few errors/warnings that provide enough detail from elm-make to do so (unused import, typos and type annotation warnings might be feasible candidates).

[ccapndave]

Sorry for the long delay - I had to go and work on non Elm stuff for a while :)

As a very temporary measure that could possibly be implemented without much effort what about simply doing a naive search/replace in the string returned from elm-make --report=json? These are the codes for 'start yellow' and 'end yellow`:

\u001b[33m \u001b[0m

If you turned these two patterns into @@ and strip out everything else as is currently happening then that would let us see where the errors are occurring without having to do any fancy parsing or anything.

[rundis]

With the latest distribution of elm-lang the ansi codes for colors are no longer part of the json output. A little weird to make fixes and not upping the version number, but it was a quick fix from Evan to make the debugger not crash for elm-reactor I believe. (I also think the ansi codes didn't play well with elm-reactor...). I also think the reason they did show up in the json output (ref #4) was that the terminal detection feature of elm-make had a bug.

Short story is, I can't rely on the ansi color codes being present (:

Example output using the latest elm distribution (os/x)

elm-make Game.elm --report=json --output=/dev/null
[{"tag":"unused import","overview":"Module `Random` is unused.","details":"Best to remove it. Don't save code quality for later!","region":{"start":{"line":4,"column":1},"end":{"line":4,"column":14}},"type":"warning","file":"Game.elm"}]
[{"tag":"TYPE MISMATCH","overview":"The type annotation for `nisse` does not match its definition.","subregion":null,"details":"The type annotation is saying:\n\n    Int\n    -> { id : ..., isMine : ..., isRevealed : ..., threatCount : ... }\n    -> Int\n\nBut I am inferring that the definition has this type:\n\n    Int -> { b | idx : ... } -> a\n\nHint: I compared the record fields and found some potential typos.\n    \n    id <-> idx","region":{"start":{"line":16,"column":9},"end":{"line":16,"column":27}},"type":"error","file":"Game.elm"}]

command line:

[rundis]

I've added a feature request to elm-make. Currently tracked in https://github.com/elm-lang/elm-make/issues/98 will reopen when something surfaces.