3 ms·
go-mode (at least used to) have a bug in the auto-indent code that would occasionally throw it into an infinite loop. This should only affect the buffer with t
by LukeShu 13y ago
go-mode (at least used to) have a bug in the auto-indent code that would occasionally throw it into an infinite loop. This should only affect the buffer with the code being indented. I should be able to switch buffers, switch to another frame, and edit other code. I should be able to kill the buffer. However, I can't, as the lisp is stuck trying to parse go code that can't be parsed. Now, my Emacs session, which may include several unsaved files, my IRC sessions, and connections to remote hosts, must be killed.
- hollerith 13y agoNow I see: great grandparent's "emacs buffer locks up" refers to the (multi-threaded) way he (and probably you) wish Emacs worked, not the way it actually works. Typing control-G does not get you out of the infinite loop?
- gavinpc 13y agoBoth this and problems like LukeShu mentioned. For example, I had a problem where org-mode would hang in certain cases when using \mdash with pretty-entites turned on. Or csharp-mode would hang when editing around preprocessor directives. Emacs becomes non-responsive in such cases. It would be cool if I could just close that buffer, like a browser tab that had crashed. This and the fact that all async processing has to be done through OS jobs (or something like that) make it unsuitable as a replacement for many kinds of app.
- xyzzy123 13y agoWhen you're using zenirc and Gnus all day as well as editing, network issues also block emacs. Which is why I stopped doing that.