5 ms·

This article was interesting: http://tkf.github.io/2013/06/04/Emacs-is-dead.html http://tkf.github.io/2013/06/04/Emacs-is-dead.html The lack of multi-threadin

by gavinpc 13y ago

This article was interesting: http://tkf.github.io/2013/06/04/Emacs-is-dead.html http://tkf.github.io/2013/06/04/Emacs-is-dead.html The lack of multi-threading is #1 on his list, and it seems to me for good reason. If one of my emacs buffers locks up (which can happen for any number of reasons), the whole session is hosed. Notwithstanding that, one thing I'd love to see is an FTP client mode something like FileZilla.

math0ne 13y ago
There is many filezilla'esk ways of accessing files over ftp and ash in emacs. Two are: Dried Sunrisecommander
hollerith 13y ago
>If one of my emacs buffers locks up (which can happen for any number of reasons), the whole session is hosed. I have used Emacs every non-vacation day for the last 22 years, starting with version 18 and extending through version 24, on over a dozen computers, on Linux, OS X and a proprietary Unix, in text mode and with a GUI. I think I understand Emacs internals pretty well, and I cannot imagine what you mean by "if one of my Emacs buffers locks up".
- 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 ago
    Now 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 ago
      Both 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 ago
        When you're using zenirc and Gnus all day as well as editing, network issues also block emacs. Which is why I stopped doing that.
kindahero 13y ago
And the work on preliminary thread support is well under way..
chriswarbo 13y ago
Concurrent != parallel != multi-threaded Threads are WorseIsBetter concurrency which break pretty-much everything they touch. Elisp would be best without them, and use a sane concurrency mechanism like asynchronous events (like Node/Erlang). This would require private variables (ie. lexical scope), and that the interpreter be aware of what is accessed from each scope, so that concurrent code can be run in parallel. Switching to Scheme (Guile) would be the first step. What I'd really like to see is an editor with an FRP interface. That won't happen with Emacs though, since it's too big a leap in philosophy.

by gavinpc 13y ago

math0ne 13y ago

There is many filezilla'esk ways of accessing files over ftp and ash in emacs. Two are: Dried Sunrisecommander

hollerith 13y ago

>If one of my emacs buffers locks up (which can happen for any number of reasons), the whole session is hosed. I have used Emacs every non-vacation day for the last 22 years, starting with version 18 and extending through version 24, on over a dozen computers, on Linux, OS X and a proprietary Unix, in text mode and with a GUI. I think I understand Emacs internals pretty well, and I cannot imagine what you mean by "if one of my Emacs buffers locks up".

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 ago
  Now 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 ago
    Both 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 ago
      When you're using zenirc and Gnus all day as well as editing, network issues also block emacs. Which is why I stopped doing that.

kindahero 13y ago

And the work on preliminary thread support is well under way..

chriswarbo 13y ago

Concurrent != parallel != multi-threaded Threads are WorseIsBetter concurrency which break pretty-much everything they touch. Elisp would be best without them, and use a sane concurrency mechanism like asynchronous events (like Node/Erlang). This would require private variables (ie. lexical scope), and that the interpreter be aware of what is accessed from each scope, so that concurrent code can be run in parallel. Switching to Scheme (Guile) would be the first step. What I'd really like to see is an editor with an FRP interface. That won't happen with Emacs though, since it's too big a leap in philosophy.