Open petergaultney opened 3 months ago
This error case can definitely be handled better. Could you try a copilot-reinstall-server
and report back?
Thanks for the response.
copilot-reinstall-server
failed for reasons having to do with asdf
being... randomly broken. Unfortunately that error was hard to interpret as well. While I was trying to debug what was wrong with asdf
, I kept trying to open files (e.g. .tool-versions
with emacs, and every time i tried to open a file, emacs would hang because copilot-mode was hanging on every switch to a buffer.
Emacs being single-threaded can exacerbate unfortunate problems like this one, where a plugin like copilot-mode
can essentially completely break the editor with no way to turn it off or debug it, because the emacs debugging facilities are unreachable and every buffer that gets opened tries to activate the offending plugin, resulting in infinite recursive hangs. At some point I just got lucky and happened to guess that I should try to fix everything via the command line.
I did eventually get asdf
to behave (there are a long list of my particular asdf issue out there, with no clear workaround, but eventually you can beat it into submission), and that resolved all my immediate issues.
Still, if you can think of a way to avoid suppressing the buffer switch (and also a way to, perhaps, somehow use async I/O to wait for the results of external processes?), that would really help for cases where the underlying environment is somehow misconfigured.
from Messages
there's a long pause; sometimes several seconds. Then this error. The buffer itself doesn't come up. I can't even switch to the buffer afterward - it is listed in the set of open buffers, but every attempt to switch just causes this same issue.
I see the following in copilot-events:
that seems straightforward enough, but shouldn't the failure to load copilot not 1. hang emacs and 2. stop the buffer from appearing at all?
i'm using straight.el, and the md5 of copilot.el is 24254afdb7fc64841c1f7c15786cfa14