Because flymake is too hard to set up

[deepfire]

..I have decided to steal error overlays from ghc-mod.

There's a follow-up branch with more controversial stuff in it -- overlays-extras.

[ivan-m]

Or use flycheck instead!

I have flycheck-haskell installed, and this is in my Emacs setup:

;; Make flycheck aware of sandboxes.

(eval-after-load 'flycheck
  (add-hook 'flycheck-mode-hook #'flycheck-haskell-setup))

(As well as enabling flycheck-mode in Haskell buffers.)

Note that I don't use the various keybindings, because I try and make sure I don't have any errors to check :p

(Then again, I just noticed that part of my haskell-mode-hook isn't being applied...)

[deepfire]

The trying-to-not-have-any-errors part is where the error navigation is helpful.

Also -- warnings are also overlaid, and navigatable -- when -Wall is passed to ghci.

[gracjan]

@deepfire: I see you had a productive time! Great!

Can you split this work in separate pull requests? For example all refactoring can go immediately in.

We need to NOT BREAK ghc-mod as it is used with haskell-mode.

Note haskell-load-on-visit: does ghc-mod load every file on every visit?
Note haskell-load-on-save: this was discussed and resolve was that C-x C-s C-c C-l is short enough for this functionality. Also in haskell-mode current session is used both for program inspection and program running so this loading is a bit too confusing.

[deepfire]

@gracjan:
0. the driving idea behind this pull request was to replicate the ghc-mod experience, since I decided to migrate away from it towards haskell-interactive-mode

1. on splitting: will do
2. on not breaking ghc-mod -- I need to test for that separately
3. on load-on-visit -- yes, and actually ghc-mod is even more aggressive -- it puts the checking into defadvice on switch-to-buffer
4. on load-on-save -- this is how ghc-mod does it as well. Can we have that as an option -- nil by default?
5. I want to maximize checking, but I understand other people work differently, so that's where the defcustom come in

What do you think?

[gracjan]

Thanks for the answers.

haskell-interactive-mode is currently used for shell-like interaction (eval a function) and some automatic backend-like queries (C-c C-t for example). The two do not go well together as they depend on different context. If those two sessions were split then shell-like would reload only on explicit user request and backend-like would be able to load-on-visit and load-on-safe as it wishes without problems.

We do not have that split yet.

I would love to avoid customizations as users tend to stick to the defaults, customizations need a lot of documentation written and unit test cases explode.

Have you seen flycheck-haskell and haskell-flycheck?
https://github.com/flycheck/flycheck-haskell
https://github.com/chrisdone/haskell-flycheck

[deepfire]

@gracjan, what you say makes me think..
Does it mean, that you think it would go against haskell-mode's mandate to replicate the ghc-mod experience?

[deepfire]

1. The REPL workflow must be supported, I know and love it very well, having come from Common Lisp land
2. I understand that backend queries /somewhat/ conflict with that, but it is already the case
3. As to the error-overlays part, I need to look at the various flychecks, indeed
4. There's a small, but important part of my original pull request, which can be summarized with "more automation, less questions" -- again, as a part of the attempt to replicate the ghc-mod experience -- what do you think about it?

[gracjan]

@deepfire: Actually the more I think about your code the more I like it as it is.

I did some research about possible options that we have here. Flycheck as it is now will not help us manage overlays so your overlay logic must be implemented. shell-like and backend-like sessions need to be split but that is not yet feasible.

That means your solution is best with respect to current state of affairs.

Can you please split it into a couple of pull requests? Especially each new customization variables need to be in separate prs because those require more eyes to look at.

[deepfire]

@gracjan: working on the splitting part.. but got distracted into massaging my weld tool, that aids git history rewriting..

Will present my results soonish.

[deepfire]

@gracjan: error-overlays now separate from customizations

[deepfire]

@gracjan: as to the customizations -- they are closely tied by diff conflict matters, so there's only two pieces that I can conveniently separate them in -- and only after error-overlays goes in, I guess..