Support spaces in project paths for haskell-process-load-file or haskell-process-load-or-reload with errors in source file

[gracjan]

Reference #1004.

[gracjan]

@issue-dispenser: You looked into a problem that is close in code to this one. Can you look into fixing also spaces in paths problem?

[issue-dispenser]

Is this still an issue? I successfully executed haskell-process-load-file and haskell-process-load-or-reload on ~/abc/Ubuntu One/def/def.hs in emacs -Q. It also works for ~/ab c/U b u n t u One/de f/d e e e ef.hs"
Oh, it only happens when the file has errors, got it.

[gracjan]

Changed title accordingly :)

[issue-dispenser]

Well, it appears that something else is causing the error, namely haskell-check-paint-overlay. Sadly it's undocumented so I don't really understand the contents. But this function is indeed getting called with the wrong arguments ONLY when there's a space in the file name for some reason. Called when loading a file with no spaces:

(haskell-check-paint-overlay "something.hs" t 2 {error description} "~/hello-man/something.hs" error nil 1)

and with spaces:

(haskell-check-paint-overlay "something.hs" t nil {error description} "~/hello man/something.hs" error nil nil)

So it replaces the line and coln arguments with nil, which causes the (wrong-type-argument number-or-marker-p nil) message.

The question is why the call is different.

[issue-dispenser]

Issue appears to be here (in haskell-process-errors-warnings):

(location (haskell-process-parse-error
                        (concat file ":" location-raw ": x")))

location-raw is the same between no space/space, so the spaces in file must affect all of the regex magic in haskell-process-parse-error

I really don't see why haskell-process-parse-error is being used though. The only two properties that are used in the function are line and col1, which seems like it can be directly extracted from location-raw (in the test case, location-raw is "2:1-19", line is 2, col1 is 1). There's no apparent reason for the function.

What's your take?
Edit: Confirmed -- when manually extracting the line/col1 it works.

[issue-dispenser]

Oh, I happened to look at it again and while I thought that the regex in haskell-compilation-error-regexp-alist looked pretty volatile, removing the space from the first block seems to fix the error without any other changes.

Also, looking at the regex, it seems that it doesn't support directories like Corinthian-1:13-19/something.hs (due to the #:#-#format). While it doesn't issue an error, just prints Compilation failed with no information.

[gracjan]

haskell-mode/haskell-compile.el

Line 65 in fae1875

(defconst haskell-compilation-error-regexp-alist

My take:

If reparsing error information can be avoided it should be avoided.

Then this regexp does not look right. Does GHC escape paths with spaces or just ignores the problem?

[gracjan]

GHC just ignores the problem. That means the regexp should just accept spaces in file names.

[issue-dispenser]

Right, so that should about do it for the space issue then. Are you going to bother with the support for directories with #:#-# or (#,#)-(#,#) in them (no elisp errors, but no reported Haskell errors)? Might require some refactoring.

Also, I noticed this line
(plist-get (haskell-process-parse-error final-msg) :line))
in haskell-process-errors-warnings. It looks like the line property would be the same as location's as they both use location-raw. Am I wrong?

[gracjan]

No, those super special directories do not bother me.

Can you remove the places where line is unnecesarily reparsed and add space handling to the regexp?