Open lukehoersten opened 8 years ago
Does M-x stack-mode-restart
and then disabling/re-enabling stack-mode temporarily fix this?
@chrisdone yes but any time I do a stack-mode-*
function it freezes until I C-g
again.
This seems to be the last thing left in the *stack:project*
buffer when it stops responding:
<- {"tag":"ResponseLog","contents":"[Debug] Recompile required, starting... @(ideba_3ZhTR2JwASF9jTa238ZFTP:IdeSession.Update.ExecuteSessionUpdate ./IdeSession/Update/ExecuteSessionUpdate.hs:223:5)\n"}
I've done some digging. It looks like what's happening is that stack-mode-set-initial-command
is setting up Emacs to expect a response to a command that is never sent (presumably because stack-ide used to reload targets on startup, as the docstring says, but no longer does as part of the reload rework) but with that outstanding pseudorequest pending, no other command is ever sent from emacs. Simply changing stack-mode-set-initial-command
to set stack-mode-current-command
to nil
makes the mode work for me again (at least in the toy one-file project I used to investigate), because Flycheck immediately issues a command that causes stack-ide to load the current file.
Well, for some values of "work". It seems eager to unload modules under circumstances that are not yet clear, but at least it doesn't get into a state that a quick C-c C-l can't fix.
My case doesn't look like it's even trying to initially load modules anymore. And similarly, C-c C-l
does nothing.
I can reproduce the same thing: the stack-ide buffer ends in "Recompile required, starting..." after starting the process, with no apparent compilation actually happening (there are no child processes of the stack ide process at all, for example). Is this a red herring? (I see the same output when running stack ide start
from the command line)
After that, any command that tries to interact with the subprocess just seems to hang. I'm using git master of stack-ide
and stack
revision 42bb3b35b50f93183e5c605f68e73302f3dd16db as installed by stack upgrade --git
. My emacs version is: GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.16.6) of 2015-09-19 on trouble, modified by Debian
@LukeHoersten I think I was unclear. I was seeing exactly the same symptoms as you, with the log ending at "Recompile required, starting...". What my digging showed was that from that point onward, Emacs was refusing to send any more commands at all because it was still awaiting a "response" which was really a default startup message from the backend (specifically, it was waiting for a message with the tag ResponseUpdateSession
). It doesn't look like a message of that sort is sent anymore without prompting. By making it not expect that message, it's free to send other commands.
Following @rjmac's solution I was able to see stack-mode working finally. Running stack from git Version 0.1.5.0, Git revision 06a4b270de2d2dcbd3ee8abe98078151c4a8f075 X86_64
, stack-ide from git f78ff35abfbbc52e171ee109682c85baa9deb5f1
@chrisdone any ideas on @rjmac's hint?
f78ff35a has stopped working as of stack-0.1.6.0
. reverting back to stack-0.1.5.0
fixes it. this applies to both using stack-ide from within Emacs as well as $ stack ide start
on the command line.
the solution offered by @rjmac does indeed work for me as of stack-0.1.8.0
.
After upgrading to the latest
load-targets
release ofstack-ide
,stack-mode
blocks emacs in various situations.Versions
Problem 1
On initial startup,
stack-mode
blocks emacs indefinitely. This can be unblocked by hittingC-g
numerous times.The resulting
*stack:project*
buffer looks like this (those are^H
characters):Problem 2
After
C-g
-ing the first hang, running anything like(stack-mode-goto)
hangs emacs in the same manor as above.C-g
-ing that adds only one new line to the*stack:project*
buffer:This is reproducible.