Emacs gives you tight integration for everything that could possibly be represented as a buffer. Emacs is programmable glue between applications, a better "shell".
The desire to do all things in Emacs is because Emacs lets you do it and because it reduces context switching. For more on why one would want to make Emacs do things that are not traditionally the job of an editor, see also https://elephly.net/posts/2016-02-14-ilovefs-emacs.html
But, just as it is a mistake to blindly cling to the old and comfortable, neophilia is a trap in itself. And it is a bit amusing to watch, for instance, new crops of editors repeat the same mistakes old ones got through in whatever GUI drag is trendy is this week.
For your Mac OS comparison to make any sense, you'd have to point to something comparable to lacking memory protection. So... what would that be? I have a sneaking suspicion you mean GUI integration with whatever OS you use, but I'd like to be clear.
Agree, there is always must bee a meedle path.
To answer your question about MacOS 9 comparisons, I meant technical limitations, like single threading issues, ui capabilities, you know. I may be wrong, though, I haven't paid attention to Emacs intervals for a while. Modern web-based platforms are far from perfect, but they are reacher.
Emacs lacks a couple of features and I think it's fair to say that this represents a limit, but I don't see "the rest of world [...] moving forward" in this area. I don't know of any other system that is as ambitious as Emacs, a system that embraces the overflowing kitchen sink and isn't content with just being called an editor.
Out of the box it's terrible, I give you that. Clunky and dated are too nice for describing the defaults. But underneath the extremely conservative and curmudgeon defaults lies a very flexible environment that cannot be approximated with a set of text applications running inside a terminal emulator. It's a pale shade of the same colour that made Lisp Machines so attractive.
The vi vs. Emacs editor wars are over and Emacs lost. The new struggle is between vim and modern IDEs and IDE-like editors (Atom, Sublime, etc.).
There are reasons for this. Vim is retro like beehive hairdos; Emacs is retro like casual workplace sexism. The buffer implementation in Emacs sucks. Once you start opening huge files or running shell tasks that spew a lot of output, Emacs chokes hard and because it's not multithreaded, pegs your CPU and locks up your terminal, in buffer sizes that modern editors handle easily.
Also, Elisp is slow, contains warts the Lisp community has long since fixed, and is in general a millstone around everybody's necks.
Also, the UI. Just... the UI. Wonder why the best way to get a young developer to use Emacs is to reskin it like vim (evil-mode, Spacemacs)?
Editors, even all-in-one kitchen-sink editors, have moved on from Emacs. Just let it go.
I learned vim first and later switched to Emacs because it allows me to integrate all tasks in the same work environment. The defaults are admittedly terrible and it's certainly far from perfect. But I don't see any alternative that works better for the things that I use Emacs for. I am looking forward to eventually be using Guile instead of Elisp, though.
Curious that you mention the UI as a negative(?) --- the Emacs UI is pretty good actually and it's very extensible.
While I do use Emacs as an IDE (I do some work in Clojure), I have another instance that I keep open and use solely to manage myself: email, calendar, list of to-do items and their status, miscellaneous notes, etc. At one point I had separate tools for each of these functions but over time I've decided that specialized tools aren't really worth the hassle. Emacs works just fine and everything is in one spot and easy to find.
You're completely missing the point.
Sure, some people might do it to score points with their peers, but many of us use text-based clients because it fits well within our workflows. I used to use Mutt, because I do everything except for graphical web browsing (literally) on a terminal. I switched to Gnus in Emacs because it's heavily scriptable and has very convenient integration with Org Mode.
Put another way, you can complain that a pickup truck isn't a Prius, but you should expect people who use (not just drive) pickups to snicker.
I use mutt (and vim, but that's a different post) heavily because it saves me so much time. Sure, there's a learning curve, but there is no faster mail client out there for handling large volumes of mail.
Speed:
- It is entirely keyboard driven.
- Until you have >6 figures of mail in one mbox, every action is essentially instant. And then you only wait a bit on load/save.
- If you have to deal with automated mail systems and the occasional mail disasters caused by them, the regex manipulation is a godsend.
- I think people don't notice the little delays in GUIs, but when you're going through hundreds of messages, it adds up.
Other awesome features:
- If you ever have to deal with GPG, mutt is the place to configure it. I don't use it much, but it is part of the workflow for some open source projects. I've configured it in various GUI MUAs, and it seems like every time I do try to sign something, it broke in some annoying way. Mutt is loosely coupled enough that that doesn't happen.
- Works over ssh. Yes, this absolutely matters to me - can't live without it.
- Extremely extensible. Add a configurable MDA[1]. I've built entire little adhoc apps based on email for various purposes.
[1] I actually still use procmail, because the syntax ate by brain a long time ago, but I'd recommend something less obtuse if you're starting fresh.
Mutt is a bit old-school. It absolutely assumes rather more familiarity with how mail works than most other MUAs, and the configuration isn't very... ergonomic is the wrong word, but close. Combined with man(1) style docs, there isn't a good way to distinguish obscure knobs one would rarely want to touch from things everyone configures, for instance, unless you're already pretty familiar with what's going on.
In a past life, I spent a noticeable fraction of my career dealing with email from several angles, and love mutt. But if you've made healthier choices, I can absolutely see being bewildered and frustrated by it.
Well said.
But: I have been using mu4e + Emacs for email for about two years now. I would seriously recommend anyone who already uses Emacs -- and especially if you use org-mode -- to look into it. Not because you score nerd points for reading & composing email in Emacs (frankly, you look ridiculous) but because it might just hook in perfectly with your workflow. I hardly touch any of the power user features, I do very little customization, and still it is by far the best way for me to manage my email. I also use it side by side with a web client (both Fastmail and Gmail) and switch if I need to.
How does an emacs window, even with mu4e, represent emails with meaningful formatting, inline graphics, etc? I'm guessing by launching an external viewer, but even that would slow me down quite a bit.
For basic formatting (bold text, headings, lists, links, etc etc), Emacs can render using its built in web browser. The "richer" it is, the more screwy the formatting gets. Usually you can at least read the emails.
You can easily pipe an email to your web browser of choice. This works fine but isn't exactly what you want to be doing all the time.
For my work, I am mostly dealing with plain text and attachments. The rich stuff is usually the email I care less about anyway. I don't think I'd want to use mu4e if I was dealing with rich content often. You can do it but it definitely slows you down.
I use Alpine for personal email and Gmail for my work email, and I've wasted more time configuring the latter than the former.
You must have a very different set of correspondents than I do. About the only non-bulk, non-plain text mail I get is when the office manager sticks a cute .gif in an announcement.
The Mac mail app would be totally sufficient for me if it could handle complex searches over the volume of mail I have with speed, but it just doesn't. It helps that I'm in an organization with a disproportionate number of Linux users; I don't get any Outlook attachments or other Microsoft nonsense in my inbox.
- VS/Xcode don't support keyboard macros
- VS/Xcode don't support piping selection through a shell command (I had to write an addin to do it: https://github.com/tom-seddon/VSScripts)
More generally, your window layout options in both are a lot more limited, and, worst of all, the extensibility experience in both is poor. Extensibility is basically non-existent in Xcode, and while it looks comprehensive in VS the APIs are rather unwieldy and underdocumented and the iteration time for testing is very bad.
Good extensibility support opens up many possibilities! Even with what VS gives you, you can get good stuff like Comment Reflower, or (if I say so myself) my VSScripts addin. But Emacs just does that side of things a lot better.
For example, multiple-cursors.el, which is an Emacs addon, is a huge improvement over the box selection available in VS/Xcode.
Adding reasonable support for a language to Emacs is easy to do in a couple of hours, possibly working from one of the many examples, and you can continue refining it from there. In VS by contrast options are the two extremes of "pretend it's one of the other languages VS supports already" (little better than Notepad with syntax highlighting) or "invest a week (plus) in writing an entire new language infrastructure, with no examples to work from" (I'm sure the results are good if you put the effort in though). For most under-supported languages you'll meet, Emacs is much closer to the effort/reward sweet spot.
(Xcode? I don't think you can make it support new languages at all.)
It's been a while since I used WebStorm (Javascript-oriented IDE) but my response to that was similar.