> Sort of like forcing emacs to do everything (peace be upon emacs).
Yeah, except that people force Emacs to do everything because it's more convenient and efficient to do things this way. Things within Emacs are much more interoperable than anything else[0] in your operating system - both by having a no-bullshit, powerful[1] and consistent UI, and by being designed for interoperability and third-party extension from the get-go. Basically everything that deals mostly with text - and that includes IRC, issue tracking, e-mail, etc. - is better done in Emacs than in a standalone (or God forbid, web) tool.
Emacs OS maybe a weird and unpopular mindset, but it's a very practical mindset.
--
[0] - besides maybe terminal utilities, but we're talking applications with UI here.
[1] - all the weird shortcuts doing text magic work on everything in Emacs, so the investment pays off across everything you do within this environment.
People want their muscle memory to follow them. Emacs solved it by pulling applications into Emacs. Vim/vi "solved" it by virtue of applications adapting vim keyboard conventions. "Solved" in quotes not because it's not a solution, but because the solution wasn't implemented in Vim, but in each application where a developer wanted to use their muscle memory.
An excellent compromise solution is apps that use readline: you can use either editor's muscle memory.
I have an addon installed in firefox that lets me use my Vim muscle memory in firefox.
Consider e.g. e-mail in Emacs[0] as on this screenshot: [1]. Both the list and the message you see on this screenshot are read-only UI, like in any terminal-oriented app. Except that I can navigate through and manipulate them with all my usual Emacs shortcuts, including:
- using incremental search to find a message of interest
- doing regular Emacs region selection over multiple messages, to apply the same action to many of them
- semantic expansion of selection
- using selection to spawn multiple cursors at appropriate places, and then apply the same actions under each cursor
- using M-x occur to do a "grep" on contents
- using regexp highlighting to highlight lines or words matching regexp
- using narrowing and widening to display only a subsection of the e-mail list
... and many more, and all those examples didn't even touch e-mail-mode-specific things! That's just text-editing shortcuts over text UI! Those are all the things you'll have in your muscle memory as a proficient Emacs user, and you can use them everywhere - be it IRC, terminal, a REPL, list of e-mails, etc.
In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow - and I have access to very advanced/complex actions (plus the ability to write my own, or download them from the Internet).
Oh, and even if read-only, the UI is still text, so I can just mark it all, copy over to another buffer, and process it as if I was working with a plaintext file. No need for scrapping anything.
EDIT: changed "expansion" to "widening" in the point about narrowing.
--
[0] - which I just managed to get working, thanks to friendly HNers that responded to me here: https://news.ycombinator.com/item?id=14569833.
Narrowing and widening to be precise. As many Emacs features, narrowing seems useless at first, but it has surprisingly many uses. Especially with `expand-region` installed: no matter where is my point, I can quickly select current block, narrow the buffer to it and start using bulk-edit tools, like `iedit` or `multiple-cursors` while being sure that they won't affect other parts of a file.
> In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow
I still use the combo of urxvt+tmux+zsh though. I could probably get most of the same features with Emacs+Elscreen+Eshell+Auto-Complete/Company, but setting it all up seemed like a lot of unnecessary work, while I had my `.tmux.conf` and `.zshrc` already configured before switching to Emacs. I'd still love to switch to Emacs for terminal emulation, but all the available options right now (from eshell to ansi-term) lack some important features I'd rather still have.
I have the same thoughts about available terminal options; I'd love to use Emacs for my terminal, but unfortunately there are always corner cases that annoy me enough to keep me stuck to urxvt + fish.
What's great is that the .stumpwm is just Lisp code (just like .emacs) and every window management function is available (just like in...Emacs). If there's an error somewhere, you get the full power of the condition/restart system, so your WM doesn't just crash, you can recover interactively.
And with quicklisp, there are so many Common Lisp libraries available, it becomes very easy to script StumpWM however you like...all without leaving Emacs or restarting the WM or anything inconvenient like that.
I feel like this philosophy (editing a program while it's running) isn't really found in non-Lisp languages. Which is such a shame, since I think it's really useful and cool.
I am not sure if sarcasm or what. It's way worse then IRC because it's so damn slow.
Yeah history is actually cool, because you can forget to track, but it's too easy to say "oh it is in history search for it" ... ok./
Started probably with "Twitch Plays Pokemon", "Twich Plays/Does X" means thousands and thousands of people trying to simultaneously control a single-user game or application, with the whole thing being live-streamed.
Thankfully it all came to a head when the buggy deploy bot made a broken deploy and we started using it just for plain chat and moved to free plan because we didn't want history on purpose.