Skip to content

Would it make sense for haskell-mode to highlight type errors? #888

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rrnewton opened this issue Sep 20, 2015 · 1 comment
Closed

Would it make sense for haskell-mode to highlight type errors? #888

rrnewton opened this issue Sep 20, 2015 · 1 comment

Comments

@rrnewton
Copy link
Member

I've been reading through issues like #809 discussing the ghc-mod / haskell-mode relationship.

Initially, when using modern haskell-mode, I was very surprised that my errors came up in my REPL when evaluating the buffer, but that they weren't highlighted in the source. In fact, as of current HEAD (d11f7b2), pressing enter on the message in the REPL kindly highlights and switches to the error, which is great.

But it sure would be nice for that to happen eagerly rather than lazily, via switching buffers and clicking on each error. Indeed, being able to see error messages before even taking eyes off the code is such an addictive aspect of using ghc-mod. And it would be great to have that even with just haskell-mode.

I haven't found any docs that address this, so I think it would be nice if there's one place that contains the answer to this question. That is -- is it hard or non-sensible for some reason to go back and paint the relevant buffers with highlights at the point all these error messages are discovered?

@rrnewton
Copy link
Member Author

Wait, nevermind, it looks like this is in fact working just fine!!

I'm not sure why I was initially having trouble. Now haskell-goto-next-error works, and there is in fact highlighting on the error lines.

Wow! Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant