Run 'stack ghc' from project root instead of directory of current file

[mrkkrp]

Run 'stack ghc' from project root instead of directory of current file

[swsnr]

I'm sorry to say that you can't currently change the working directory in Flycheck. It's a long standing issue, see flycheck/flycheck#312, but it's not a priority for me, because I'm personally not affected by this short coming of Flycheck.

It's also not that easy to implement as it needs a rather deep change to the internal API for picking syntax checkers, because we need to compute the working directory before starting the syntax check and then drag it along all the way to error parsing to properly resolve relative file names. Unfortunately Flycheck does not provide any infrastructure for this currently.

I'm closing this issue since it's essentially an upstream problem in Flycheck itself.

[mrkkrp]

Implementing this will make me diverge from schedule… On the other hand I cannot really continue without tools that work in my circumstances. So it turns out that this things has been waiting for me.

I like that idea with :cwd described by @rejeep. I think that's how it should work.

Can you describe step by step how this feature should be implemented properly (how you would implement it if you had time and motivation) from your point of view? (E.g. start here, because …, then implement …, change …, etc.). I don't really know how Flycheck works and typically I need to spend several hours to be in position to contribute to large projects. If you could give me some hints your several minutes would save me several hours (or more).

[swsnr]

@mrkkrp I'm sorry, but I do not know how I'd implement it. If I did I'd have written it down on the corresponding issue.

I do know, though, that it is not an easy change. There are two challenges that I see immediately:

• Flycheck implicitly relies on default-directory in many places. Specifically we do expand-directory with no directory argument all over the place. An implementation needs to identify all these places, decide whether they need the buffer's default-directory or really the working directory of the syntax checker, and make sure to pass the checker's working directory to all these places.
• Flycheck needs to access the working directory at two different places that are somewhat "far away" from each other: The invocation of the syntax checker, and then the expansion of relative filenames after error parsing. To make sure that the working directory matches at both places we cannot re-compute it at the second place; instead Flycheck must pass the working directory used for checker invocation all the way through the process sentinel and error parsing.

Currently we attach a couple of ad hoc properties to the process object but I'd not like to expand this “strategy”. As part of this change I'd like to see a generic "syntax checking context" struct being introduced that wraps up all the information about the current syntax check (i.e. checker being used, buffer being checked, and then also the working directory) and makes that available at all later places, e.g. error parsing, error filtering, etc.

[mrkkrp]

All this stuff makes me feel very sad.

[swsnr]

@mrkkrp I didn't anticipate this use case when I wrote these parts of Flycheck, and it's all too easy to rely on all the implicit global state in Emacs. Besides, with this design decision being so close to Flycheck's core it's also one of the oldest decisions in Flycheck, and my Emacs Lisp skills and my understanding of Emacs were worse than they are today back then.

I'm sorry that my work is not good enough for your requirements.

[mrkkrp]

@lunaryorn, No worries, Flycheck is great, that thing is my problem.

[swsnr]

@mrkkrp Thank you 😊 Please don't hesitate to ask if you need any help and I'll do my very best to help you!