5 ms·

I'm really hoping that Emacs becomes multithreaded somehow. Or at least improves some operations so that they're non-blocking. I've been using Emacs primarily

I'm really hoping that Emacs becomes multithreaded somehow. Or at least improves some operations so that they're non-blocking. I've been using Emacs primarily for org-mode/roam/babel for a few years now. I'm very glad for its existence, I really think I've become a more effective DevOps person because of it.

wyuenho 4y ago
I'll be entirely satisfied with a process/event queue/loop that we can submit tasks to like Javascript's. There is already a command loop in Emacs, we just can't use it for anything other than input events and commands. Once we have an good event loop, we can build a state machine like Redux on it, then we can start rebuilding the display machinery, then we can start deleting all those hooks that constantly interfere with each other...
- ywei3410 4y ago
  It already has a process/event queue like JS since Emacs 26. What did you mean in particular?
  - wyuenho 4y ago
    What did YOU mean in particular?
    - ywei3410 4y ago
      I meant exactly that, both core JS and ELisp share the same model of a global interpreter where blocks of code can be interleaved and yielded (both manually and in response to external events). I wanted to know what in particular about JS you were missing.
      - wyuenho 4y ago
        You have been able to emulate cooperative multitasking using callbacks since at least the 70s with lisp. There's always been some form of concurrency in any lisp, the problem is, the event listening/emitter pattern is pretty much not a thing in Emacs, so you can't fire a custom event and hope it will drop into the event loop and get responded to by whatever is listening, because it's not an event loop, it's a command loop. The types of events you can respond to is fixed.
tmalsburg2 4y ago
Emacs does have threads: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...
- bloopernova 4y ago
  I probably didn't use the right terminology. I mean that if I list-packages then U, then x to start updating, I should be able to go back to my editor and continue working.
  - tmalsburg2 4y ago
    I think a lot of packages are not yet using threads. And to be honest, I'm a bit scared of packages starting to use threads because there are a million ways in which you can mess up with threads especially given Emacs’ architecture. What if two threads start manipulating the same buffer? Emacs wasn’t built with these scenarios in mind. But perhaps I'm too pessimistic and there are good answers for that.
    - morelisp 4y ago
      I was sad the day I saw Emacs implemented threads before a proper async event loop / futures / etc. Do those first, see what kinds of concurrent code people actually want to write, then write a multithreaded scheduler for that. Instead it’s backwards, now we have hard-to-use concurrency primitives and still shitty UIs.
    - TeMPOraL 4y ago
      I want to see good interactive tools for working with and introspecting threads / async / other concurrency models first. In general, because I don't know of any, and in Emacs in particular. My current experience with Emacs concurrency is mostly negative - occasionally, an async-heavy package (like e.g. Magit-style UI for Docker) will break, and I find it hard to figure out why. Futures-heavy code I've seen tends to keep critical data local (lexically let-bound), which is the opposite of what you want in a malleable system like Emacs. For example, I'd like to have a way to list all unresolved futures everywhere in Emacs, the way I can with e.g. external processes. But it seems that at least the async library used (aio, IIRC) is not designed for that.
s0l1dsnak3123 4y ago
Indeed, I'm using Emacs for Code, reading/writing documents and emails, as well as consuming RSS feeds. The ecosystem and values that underpin Emacs are fantastic - in my personal case the only downside to heavy use of Emacs is that it can struggle to utilise my hardware. This tends to be particularly noticeable when using TRAMP and Eglot, or producing large org tables.
- Siira 4y ago
  Running emacs in tmux over SSH can be faster than TRAMP. TRAMP gets very biggy when you have a lot of third-party elisp extensions.
ilyt 4y ago
Yeah the extra micro-waits introduced by some IDE-like features were annoying last time I used it.
- deagle50 4y ago
  Hope is on the horizon: https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...
  - rs_rs_rs_rs_rs 4y ago
    This is excellent!
chlorion 4y ago
I don't think it needs to become multithreaded, it just needs better support for async/event loop style concurrency! Right now we can run subprocesses without blocking anything with "make-process", but interacting with the process is pretty clunky, and you have to use the process sentinel and filter to perform callbacks when the process changes state or exits. There is quite a lot of boilerplate to setup for all of this and the control flow is pretty confusing IMO. A nice "async/await" style interface to these things could really go a long way I think!

wyuenho 4y ago

I'll be entirely satisfied with a process/event queue/loop that we can submit tasks to like Javascript's. There is already a command loop in Emacs, we just can't use it for anything other than input events and commands. Once we have an good event loop, we can build a state machine like Redux on it, then we can start rebuilding the display machinery, then we can start deleting all those hooks that constantly interfere with each other...

ywei3410 4y ago
It already has a process/event queue like JS since Emacs 26. What did you mean in particular?
- wyuenho 4y ago
  What did YOU mean in particular?
  - ywei3410 4y ago
    I meant exactly that, both core JS and ELisp share the same model of a global interpreter where blocks of code can be interleaved and yielded (both manually and in response to external events). I wanted to know what in particular about JS you were missing.
    - wyuenho 4y ago
      You have been able to emulate cooperative multitasking using callbacks since at least the 70s with lisp. There's always been some form of concurrency in any lisp, the problem is, the event listening/emitter pattern is pretty much not a thing in Emacs, so you can't fire a custom event and hope it will drop into the event loop and get responded to by whatever is listening, because it's not an event loop, it's a command loop. The types of events you can respond to is fixed.

tmalsburg2 4y ago

Emacs does have threads: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

bloopernova 4y ago
I probably didn't use the right terminology. I mean that if I list-packages then U, then x to start updating, I should be able to go back to my editor and continue working.
- tmalsburg2 4y ago
  I think a lot of packages are not yet using threads. And to be honest, I'm a bit scared of packages starting to use threads because there are a million ways in which you can mess up with threads especially given Emacs’ architecture. What if two threads start manipulating the same buffer? Emacs wasn’t built with these scenarios in mind. But perhaps I'm too pessimistic and there are good answers for that.
  - morelisp 4y ago
    I was sad the day I saw Emacs implemented threads before a proper async event loop / futures / etc. Do those first, see what kinds of concurrent code people actually want to write, then write a multithreaded scheduler for that. Instead it’s backwards, now we have hard-to-use concurrency primitives and still shitty UIs.
  - TeMPOraL 4y ago
    I want to see good interactive tools for working with and introspecting threads / async / other concurrency models first. In general, because I don't know of any, and in Emacs in particular. My current experience with Emacs concurrency is mostly negative - occasionally, an async-heavy package (like e.g. Magit-style UI for Docker) will break, and I find it hard to figure out why. Futures-heavy code I've seen tends to keep critical data local (lexically let-bound), which is the opposite of what you want in a malleable system like Emacs. For example, I'd like to have a way to list all unresolved futures everywhere in Emacs, the way I can with e.g. external processes. But it seems that at least the async library used (aio, IIRC) is not designed for that.

s0l1dsnak3123 4y ago

Indeed, I'm using Emacs for Code, reading/writing documents and emails, as well as consuming RSS feeds. The ecosystem and values that underpin Emacs are fantastic - in my personal case the only downside to heavy use of Emacs is that it can struggle to utilise my hardware. This tends to be particularly noticeable when using TRAMP and Eglot, or producing large org tables.

Siira 4y ago
Running emacs in tmux over SSH can be faster than TRAMP. TRAMP gets very biggy when you have a lot of third-party elisp extensions.

ilyt 4y ago

Yeah the extra micro-waits introduced by some IDE-like features were annoying last time I used it.

deagle50 4y ago
Hope is on the horizon: https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...
- rs_rs_rs_rs_rs 4y ago
  This is excellent!

chlorion 4y ago

I don't think it needs to become multithreaded, it just needs better support for async/event loop style concurrency! Right now we can run subprocesses without blocking anything with "make-process", but interacting with the process is pretty clunky, and you have to use the process sentinel and filter to perform callbacks when the process changes state or exits. There is quite a lot of boilerplate to setup for all of this and the control flow is pretty confusing IMO. A nice "async/await" style interface to these things could really go a long way I think!