Open andreineculau opened 9 years ago
Hm, I think this sounds like a bit of a hairy prospect. Hacking timestamps and keeping multiple copies of the same module on the path sounds error prone. Is there any way you could make the warnings stand out more?
I thought of forbidding buffer save if there are errors, but then i realized that's just a workaround. Edts compiles in order to "lint" ie. get errors.
The key issue would still remain.
On 30 Aug 2015, at 13:29, Thomas Järvstrand notifications@github.com wrote:
Hm, I think this sounds like a bit of a hairy prospect. Hacking timestamps and keeping multiple copies of the same module on the path sounds error prone. Is there any way you could make the warnings stand out more?
— Reply to this email directly or view it on GitHub.
Hej Thomas :)
Long story short is that I have a dev environment which treats warnings e.g. "unused variable" as errors, but I noticed I get red-handed when using edts, because edts compiles the module, outputs it into the conventional ebin folder, shows the errors, but I miss them, code runs fine, I go into my shell to run "make" (which usually spits out the errors/warnings), but this time make just skips compiling the module altogether (edts just compile the beam afterall, so the timestamp is newer), thus skipping the errors/warnings as well.
I looked through the edts code and it seems that it is by design https://github.com/tjarvstrand/edts/blob/3af8770317a99497c69499692e151ce1ec20806b/lib/edts/src/edts_code.erl#L519
unlike flycheck for instance which compiles the beam inside a temp directory https://github.com/flycheck/flycheck/blob/master/flycheck.el#L6059
Unless the output directory can be changed, how about compiling but keeping to the old beam's modified timestamp? Or slightly less confusing - setting the beam's modified timestamp to 1 second earlier than the module?
Thanks!
Relates to #196, #44