Don't override M-n without permission/configuration

[bitemyapp]

Making M-n something other than next-error is annoying and breaks everything else.

[gracjan]

@deepfire: Serge, can you look at this? I think we have a keybinding conflict here.

[deepfire]

@gracjan, there are two questions at play:

1. why ghc-mod people get away with that, and haskell-mode cant? I think I sort of understand the question
2. what would be the alternative keybinding?

[deepfire]

Also: M-n and M-p were picked /exactly/ because they simulate next-error/previous-error.

@bitemyapp, what is the clash with?

[bitemyapp]

@deepfire flycheck, which I use for hlint / type errors.

why ghc-mod people get away with that, and haskell-mode cant? I think I sort of understand the question

They shouldn't be doing it either, but I stopped using ghc-mod because how fragile it was already.

[gracjan]

Flycheck uses C-c ! n and C-c ! p.

http://www.flycheck.org/manual/0.23/Navigating-errors.html

[bitemyapp]

@gracjan right but it works if you invoke next-error which is what M-n should be assigned to by default. Flycheck uses those shortcuts in part so it doesn't clobber the default.

next-error is a pretty old thing: https://www.gnu.org/software/emacs/manual/html_node/emacs/Compilation-Mode.html

[gracjan]

I see nothing about next-error in flycheck documentation. Make-mode rebinds M-n for its own purpose, ghc-mod does the same. Why is it okay for them and at the same time not okay for Haskell-mode?

[deepfire]

@bitemyapp, do I understand it right, that flycheck somehow integrates into next-error?

[ivan-m]

From what I understood from bytemyapp, flycheck does not integrate next-error, and specifically uses keybindings that don't override the ones used by next-error.

Indeed, if I try and use flycheck I can't get M-n to do anything.

When I look do a describe-function next-error, I'm told that the keybindings are C-x , M-g n, M-g M-n`.

Furthermore, I know at least magit re-uses M-n.

According to the Emacs manual, M-n is used for compilation-next-error, and seems to be only enabled in the compilation-mode (including grep-mode).

As it stands, the current default next-error keybindings are indeed working in haskell-mode. M-n does indeed clobber the one for compilation-next-error though.

(To be more clear, since I couldn't see anyone else making this distinction earlier on: this is referring to behaviour in haskell-interactive-mode, rather than when editing actual Haskell code.)

[gracjan]

Issue #821 should get this usability part fixed as a side effect.

[purcell]

Yep, I use M-n and M-p for other things, so I don't like that they're overridden. I can (and have) worked around that in my own config but in fact, since I use flycheck for compiler warnings, I'd actually like to be able to disable all the special overlay and fringe handling which is currently unconditionally triggered by loading the current file. But that may be a separate issue.

[purcell]

I can imagine a haskell-after-load-hook, such that functions added to this hook would be passed a list of errors/warnings etc. The default hook list would include a function which marks up the current buffer with overlays/fringe annotations etc. Then I could disable that hook, or add my own handlers as desired.

[geraldus]

imagine a haskell-after-load-hook

Sounds good.

[bitemyapp]

@gracjan @deepfire where's this at?