I consider to start using emacs for IRC, SQL, Shell and maybe twitter and Feed reading. But than I wonder how power users of emacs deal with emacs being single threaded.

So if I have one long-running task, like updating melpa packages, I can not switch to IRC, because emacs is blocked, isn't it?

And by the way: Emacs is one global beast. In programming I try to encapsulate functionality and shield one component from unintentionally breaking the other.

Emacs is configured as one piece and I already experienced how one minor mode interacts terribly with another one.

Or is it best practice to have different emacs processes and configurations for different tasks like IRC, email, etc?

2 Answers 2


Entirely up to you, really. I don't think there is any agreed "best practice" here. Your concerns are perfectly valid, so it's certainly not unreasonable to isolate distinct use-cases as separate Emacs instances (especially if you are less-willing to restart some of them than others). If you're happy with how you can switch between them, I'd suggest you probably have little reason not to do it.


You have a valid concern, but that does not mean there are no work-arounds. I'll list those here. But first, let me say that being able to edit, compile, and reload sections of the editor while parts of it is running is considered great convenience by expert users and developers of emacs alike. That kind of instant fixability is why emacs turns into a lifelong addiction.

...one long-running task, like updating melpa packages...

Thankfully Artur Malabarba solved that problem through his paradox package system, which has modernized updating so you don't have to wait for one long-running task to complete before switching to IRC. Check it out.

...shield one component from unintentionally breaking the other.

Emacs has something called modes feature that provides for isolation of components, granular functionality, and unmatched stability. Users, be they new or experienced, can isolate functionalities to specific modes of operation. So you can use a shortcut key such as M-n in both IRC and Paradox-Packages buffers to go to the next line. M-n looks and behaves the same in seemingly different buffers, but the actual command M-n executes in each buffer is different. Shielding happens when the command for IRC is not executed in some other buffer. Yet there is an integration: a similarity, a continuity of functionality that persists across modes. This is what gives emacs its ease of use, glue, familiarity. This is where the benefits of emacs quickly accrue.

Emacs is one global beast.

Assuming you are talking about the initialization files, sure you can store all customizations in big file -- only if you want it that way. Many also load multiple init files. For example, look at Emacs Starter Kit that distributes functionality across many files. This is purely a matter of style and convenience and not something emacs imposes. As others have said here, you choose how complex you want to get. Emacs will not hold you back.

...is it best practice to have different emacs processes...

No. The best practice is to use whatever is comfortable. For example, some packages, such Paradox mentioned above, start another emacs process in the background without the user learning async tricks. New users can benefit from such behind-the-scenes improvements with no additional tweaking of the init files.

How you incorporate emacs into your workflow is entirely up to you. You can make the beast tap dance to any global tune.

  • Thomas is not talking about initialization files; he's talking about the fact that most of Emacs' state is globally accessible to elisp (by design; it's a double-edged sword), such that a badly-behaved library could mess it up for everything else.
    – phils
    Oct 5, 2015 at 1:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.