Hacker News Reader

Comment by gavinpc | Hacker News Reader

This article was interesting:

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.

View on HN

>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".

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.

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?

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.

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.

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.

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

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

Dried

Sunrisecommander

Reply on news.ycombinator.com