#178 add problem parse language fallback

[nittka]

This PR implements the language fallback discussed in #178. Mostly, it is refactoring splitting up of the previously static parse method. There is a second reason for introducing state to the problem parser. Determining the file with the issue will have to be adapted. The current implementation can easily fail for more complex include constallations.

Checking the path against the include information present in the index may help improve finding the file to mark.

[nittka]

Determining the path for windows failed for absolute locations (absolute imports or search path imports were transformed to absolute paths in the compile output) as the path itself contained a colon. So I refined the split of the line. Further finding the included file in the workspace was improved.

[nittka]

I suggest 2 variants of testing the markers for non-workspace files. Create a main file score.ly in the workspace. Create two files you include there (both with some error/warning causing issue, e.g. a syntax error).

• one in a separate workspace project (which you then close)
• one in a completely different location If you now compile score.ly, there should be links in the console that open the two files (without this PR the issues should be there but not with a link).

[nittka]

I have removed the pdf annotation.

[thSoft]

Unfortunately during manual testing, I found that a problem hyperlink to an external file opens an editor for the path in the workspace instead of the actual external file, which results in an editor with the error "Resource does not exist".

[nittka]

I will check this behaviour on my linux machine and hopefully come up with a version that works both for windows and linux.

[nittka]

I could reproduce the problem you describe as follows:

• include a file with errors in a different project
• compile
• close the other project
• click the console link to the error file
• then I get the "resource does not exist" error

But I think, there is not much that can be done about that problem (except getting rid of IMarker-links altogether). When the console output is created, the IMarker to an existing IFile is created. When closing the project, the file is "removed" from the workspace. Could you please confirm, that this is the way to reproduce the behaviour you described. If you close the project before compiling, this problem should not occur.

I also noticed on my Linux machine, that link creation may not occur for relative includes to files outside the workspace. With the current implementation, no resolved file is found and hence links are not created at all. I'll address this issue...

[thSoft]

Okay, I understand. Thanks!