Error message file/module names at the bottom

Elm has some pretty good compiler error messages. When you have errors in multiple modules you get a nice little separator between them:

                                          Admin.Config.Orders.OrderTotals  ↑    
====o======================================================================o====
    ↓  Admin.Config.Basic


-- TYPE MISMATCH ------------------------------------ src/Admin/Config/Basic.elm

Okay so maybe it’s a little redundant to have the module name and the filename, but I find this separator really helpful. However, I often code with a split with the editor on the left and on the right a terminal running a watcher which re-compiles the code each time I save an Elm source code file. Elm’s error messages can be verbose, enough that the top of the last error message has scrolled out of view off the top of the terminal. Now my editor will generally help me find the error, but it’s quicker if I can just open up the correct file. So that would be greatly helped by having the module separator at the bottom, albeit obviously with no downwards module:

                                          Admin.Config.Orders.OrderTotals  ↑    
===========================================================================o====

That way the programmer wouldn’t need to scroll the terminal to find the filename.

I’m just posting here to see if anyone else shares this desire, and/or perhaps any other comments on errors.

P.S. elm-review has the same scheme and hence the same “issue”.

1 Like

FWIW

I used to have the same setup as you until I switched to vscode with elm-language-client a couple of months ago. Haven’t looked back since.

There’s a terminal(s) pane which includes a Problem tab that lists all problems (Elm error messages) in the current file, or any files that the current file imports. Clicking on the problem takes you to the offending line of code, opening the file if required. A double-click selects the specific offender. So if I had the following typo: Json.Decode.succeeds double clicking selects that code, and then I can simply rightArrow then delete to remove the trailing s.

It also picks up problems in the file even if it is not yet imported into the main codebase - which a watcher/compiler can’t do because the compiler only picks up errors in the imported tree of files it compiles from Main.elm down. So I can flesh out a new module knowing that when I import into into another module, it will all compile fine.

There’s many other ways in which vscode helps me, maybe I was just lazy with my previous editor, sublime, but I find vscode to be excellent; it’s not only an editor but a tool that increases my productivity.

I’m far from a fan of MS, but credit where credit’s due, with vscode I think they’ve nailed it, and with elm-language-client too, working with Elm truly is “delightful” :slight_smile:

1 Like

Thanks. That’s definitely a good reply, I have used VSCode in the past. However, I tend to use nvim now (which still comes with some pretty good support via the elm-tooling). Sometimes the error messages are too long to read in the ‘pop-up’, but I guess that’s an nvim problem.

That’s a great point.

Agree, error location at the bottom would be great. I also find myself scrolling a lot in the terminal to find the problem module.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.