Only the first line of multiline Haskell errors is displayed

[nponeccop]

No description provided.

[slycelote]

Why was this issue closed? Doesn't seem to be fixed.

[lcd047]

@slycelote: Because at the time the issue was one year old, syntastic has changed a lot since that date, and I know nothing about Haskell. As nobody re-opened it, either nobody uses the Haskell checker, or the problem has magically gone away, or nobody knows how to solve it, or nobody who knows how to solve it can be bothered. :)

Please feel free to re-open it, perhaps describing how to reproduce the problem.

[slycelote]

@lcd047 It seems I don't have necessary permissions to reopen.
Here is how to reproduce. Use the following code:

main :: IO ()
main = do
    name <- getLine
    greet <- getLine
    putStrLn $ greet ++ ", " ++ name

f ::  IO ()
f = do
    name <- getLine
    greet <- getLine
    putStrLn $ greet ++ ", " ++ name

Syntastic produces a warning on line 3: Reduce duplication. Full output from ghc-mod lint: test2.hs:3:5: Warning: Reduce duplicationFound: name <- getLine greet <- getLine putStrLn $ greet ++ ", " ++ nameWhy not: Combine with test2.hs:9:5

My ghc-mod version 2.0.3, ghc version 7.4.1.

[lcd047]

Surely there must be some newlines in there? :) Sadly I have no reasonably easy way to install ghc-mod to check for myself.

[zenzike]

ghc-mod uses a separate tool, hlint, when the lint option is passed. Sadly, ghc-mod swallows up the newlines that hlint produces. I think that syntastic should probably be using hlint separately anyway, since currently the syntastic ghc-mod plugin does too much: both a check and lint phase, when it's not always desirable to have a lint phase.

[lcd047]

As I said, I don't know anything about Haskell. Somebody who does would have to look into it. shrug

[zenzike]

Ugh, things go a little further than I thought: rather than newlines, ghc-mod outputs <Nul> characters instead of newlines (in vim, these are displayed as ^@ when you open a file that contains the output). I don't know how to make the errorformat flags deal with these beasts. The pull request above solves part of the problem by not relying on ghc-mod for everything, but for ghc-mod check the problem remains.

[lcd047]

This may not be what it looks. Vim stores <Nul> characters as <NL>, which means it occasionally confuses them. It's one of the murkier areas of Vim, f.i. system() returns lines separated by <Nul>s. It's probably a good idea to check the actual characters with something like od.

[zenzike]

I stripped down the output to contain only the character in question, and the output of od -x is:

0a00

Looks like this is a 00, which would make it <Nul>. (also confirmed by searching for CTRL-V 000 in vim, see :h NL-used-for-Nul).

[lcd047]

0a00 in od -x output is <Nul> followed by <NL> (I'm assuming little endian).

[zenzike]

Yes exactly (I'm also assuming little endian).

[slycelote]

Thanks @zenzike for figuring out the issue. The problem with current solution is that only one of the checkers is run. In my example above, there will be a warning at line 3 ('Reduce duplication') or a warning at line 7 ('Unused definition'), depending on the order of checkers in g:syntastic_haskell_checkers variable. Is it possible to get them both running?

What do you think of an alternative solution: write a wrapper script that would replace Nul characters with \n? This script could be written in Haskell so as not to create additional dependencies.

[zenzike]

@slycelote nice observation. I think that it's a slightly different issue though: syntastic has it such that if there are multiple checkers then they are in sequence. I've reported this as a feature request in #744. I think it's best to keep checkers as atomic parts, and let syntastic handle their composition.

As for running a wrapper script, that might be good for now: in the longer term I think we should either fix the issue directly, or ask @kazu-yamamoto to provide an argument that changes ghc-mod output (see DanielG/ghc-mod#136).

[kazu-yamamoto]

Would you explain what ghc-mod should do briefly?

[zenzike]

Currently ghc-mod would output something like the following:

Test.hs:10:3:Warning:first line\0second line\0third line
Test.hs:13:7:Warning:first line\0second line

The problem is that \0 is not understood by vim. This would be better:

Test.hs:10:3:Warning:
  first line
  second line
  third line
Test.hs:13:7:Warning:
  first line
  second line

In other words, do not use '\0' to separate lines: instead perhaps use a new line followed by two spaces.

[kazu-yamamoto]

OK. I will consider.

[eagletmt]

Actually, there is a way to handle <Nul> characters in Vim.

readfile() returns a list of lines and all <Nul> characters are replaced with a <NL> character (:help readfile()).
I'm doing this kind of hack in ghcmod-vim.

let l:tmpfile = tempname()
call system('ghc-mod check > ' . l:tmpfile)
for l:line in readfile(l:tmpfile)
  " A <NL> character in l:line indicates a <Nul> character.
endfor

Please refer to ghcmod#make() and ghcmod#async_make().
https://github.com/eagletmt/ghcmod-vim/blob/b4d702a225cb5be52cf89b087322a4a9abdc26a5/autoload/ghcmod.vim

[kazu-yamamoto]

So, the approach of @eagletmt is acceptable? Or, should ghc-mod prepare a customize mechanism for line separator?

[lcd047]

@kazu-yamamoto Yes and no. I'll add a "preprocessing" mechanism similar to the one described above by @eagletmt, provided that I can figure out how to make it work. That would be useful by itself, and it could be applied to the ghc-mod checker. But in my opinion passing <Nul> characters in error messages is an user-hostile behaviour that should be fixed, regardless of syntastic.

[kazu-yamamoto]

So, I should provide a mechanism to customize line separator, anyway. That's fine.

But what about the default value? If <nul> is hostile, what value is friendly?

If we can reach consensus, I will quickly implement it.

[lcd047]

Really, any combination of "normal", plain ASCII, non-control characters would be fine. As suggested above, a newline followed by two spaces might be a good choice.

[lcd047]

Please see #753.

[lcd047]

For what it's worth: this has been fixed in Vim 7.4b.014, <Nul> characters in system(), make, and basically everything not covered by readfile() are now replaced with \001 (ASCII SOH, or CTRL-A). I suppose Vim being in Beta for 7.4 helped. :)

Anyway, this doesn't help us much, as it will take a while for people to upgrade.

[zenzike]

Hmm, and how does \001 get represented, I wonder?

[lcd047]

Existing \001 are left alone. Obviously you can't map 256 characters injectively to 255 slots without some kind of encoding convention, and Vim doesn't even try to go there. The idea is \001 is supposedly not used much (I know, neither is <Nul>), :) and it can be mapped to something else with the existing Vim functions. This isn't worse than mapping <Nul> to <NL>. Vim is clunky, old, crappy code, and the most useful editor available. :)

[lcd047]

Re: running both ghc-mod and hlint and piling errors in a big, happy list: I added a new option g:syntastic_aggregate_errors: de9d561, or d3ded27on the preprocess branch.

[lcd047]

The <Nul> part of the problem should be fixed in Vim 7.4. Can somebody please confirm this? Any remaining problems?

[zenzike]

This works perfectly on Vim 7.4 using OS X 10.8.4.

[slycelote]

Is master branch supposed to work now? On Windows, when I trigger a multiline compilation error, I get a strange behaviour with ghc_mod checker: when I move to a line containing error marker, part of the error message interspersed with ^A symbols is displayed at the bottom together with a prompt to 'press Enter or type command to continue'. hlint checker doesn't display anything at all.

[lcd047]

The ^A characters are the former <Nul>s. I added a filter to remove them: 7eda5de.

Edit: make that 7550c86. :)

[slycelote]

Yes, seems to be working now :)

[kazu-yamamoto]

ghc-mod now provides "-b" command line option to specify a line separator string. I did not change its default value, ie a Nul string since a lot of confusion would happen.

[expipiplus1]

I'm still seeing this behavior with Vim 7.4, latest ghc-mod and syntastic.
I notice that syntastic sets -b to "" for the ghc-mod checker. As far as I can tell this is causing all the lines to become concatenated.
If I change the separator to "\n" then only the first line is displayed. Is syntastic unable to display multi-line error messages?

[lcd047]

@expipiplus1 Please open a new issue. Explain what you did, what you expected to happen, and what happened instead. If you have a test file that can be used to reproduce the problem, post that too.

[nomeata]

@expipiplus1, see #1700 for a related bug.