[szastupov]

I spent quiet some time setting up mutt or trying to make a real IDE out of vim or Emacs, but in the end it's just cargo cult and waste of time. There a modern email clients, IDEs, polished operating systems, etc., all built in this century. There is absolutely no need in wasting time scoring nerd points.

[rekado]

Emacs is not just an editor and mention it next to vim or mutt indicates that you misunderstand what Emacs tries to be.

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

[szastupov]

I get the point about Emacs being a OS, but don't you think it's kind of a dated clunky OS? Like "Mac OS 9" was, lacking memory protection and pre-emptive multitasking. Why would anyone want to be limited by technology when the rest of the world is moving forward?

[_jal]

It isn't uncommon to mistake 'new' with 'better'.

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.

[szastupov]

> But, just as it is a mistake to blindly cling to the old and comfortable, neophilia is a trap in itself.

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.

[icebraining]

The roots of the current macOS are much older than the classic Mac OS. Is that moving forward? What does it even mean?

[lottin]

It means that the OP doesn't know that he's talking about.

[rekado]

I'm still using the GNU system as my OS :) But Emacs is a very important "sub-environment" in my OS; it has a very privileged position in the process tree, much like a browser.

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.

[pyre]

Operating systems that pre-dated MacOS 9 had pre-emptive multitasking. MacOS "moved forward" by adopting one of them (NeXT OS) and building their platform on top of it. I'm really unsure what point you're trying to make here.

[szastupov]

I'm trying to say, that at that period of time, MacOS 9 was stuck in the past, even compared to Windows. This was in reference to Emacs limitations as a platform.

[bitwize]

Yeah, except no.

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.

[rekado]

I don't think your comparisons are constructive.

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.

[cmiles74]

I have to strongly disagree with your "cargo cult" and "waste of time" comment. Everyone has different needs and expectations and I have found managing my email in Emacs to be quick, easy and straightforward. This could be in part because I receive more mail that I need to read and comparatively little I need to respond to directly.

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.

[mikegerwitz]

> There is absolutely no need in wasting time scoring nerd points.

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.

[_jal]

I'm sorry it didn't work for you, but your hostility about it gives me the impression you became frustrated configuring advanced stuff that perhaps you don't understand or need. If you never, say, want to select a group of messages based on a regular expression, absolutely, stick with Outlook or whatever. If you never need different contextual handling (say, signing mail only from a particular account, add particular headers when sending to some address, etc.), then I'm sure the configurability looks stupid.

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.

[szastupov]

Sorry, I didn't mean it to be hostile. But you're right, I'm expressing my frustration, perhaps a bit sarcastically. Of course everyone's needs and preference are different, I'm not trying to say I am the source of wisdom, just sharing my thoughts, you know ;)

[_jal]

Totally fine - I do devops; software ensures my life is suffused with constant low-grade hostility.

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.

[mjhoy]

> There is absolutely no need in wasting time scoring nerd points.

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.

[uberchet]

I use emacs, but exclusively for orgmode. I thought about mutt years ago, and realized I get and receive too much mail with rich content for that to work.

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.

[mjhoy]

> represent emails with meaningful formatting

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.

[icebraining]

Setting up? What is there to set up? You configure your account info just like in any other client, and off you go.

I use Alpine for personal email and Gmail for my work email, and I've wasted more time configuring the latter than the former.

[gkya]

People work in different ways. I live in emacs and am a humanities student, nobody sees my computer and I don't have a friend that can quit vi for his life, but I use the software that I use because it worjs the best for me. I have a very organised inbox, a good list of feeds, and a nice setup for org and orgexport. I can create jawdropping document with a quarter of the effort my peers spend to create a half arsed one in Word. I am on top of all thenews with asimple press of the G button in elfeed and 15 minutes readin, while my peers miss exams because nobodytold them. The only place I am behind is Facebook which I deliberately don't use. So no need for blanket dismissals.

[Longhanks]

While email has evolved from plain text to mostly HTML (apart from mailing lists), code still ist text only. Vim is a perfectly valid text editor and productivity in software engineering is not defined by how much your IDE can do.

[__jal]

> While email has evolved from plain text to mostly HTML

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.

[fusiongyro]

I use IntelliJ for coding and Emacs for mail (mu4e) and the combination seems to be good for me. Emacs is great for editing code, but for Java and SQL, IntelliJ does so much more.

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.

[nazri1]

The thing is an IDE can only do so much - depending solely on the IDE mean your ability to change/refactor the code is limited to exactly what the IDE gives you. If you need to do something that the IDE can't do for you then you're stuck. This is when being competent in Vim/Emacs/Shell is an advantage.

[szastupov]

But you can extend IDEs just as well as you extend your vim/emacs. Not to mention, that for some users it's more convenient to hack extensions in Python (Sublime), Javascript/Coffee (Atom) or Typescript (vscode), rather than in weird dialect of lisp (lisp is cool, I encourage everyone to go and read SICP, but not elisp) or even worse, vim script.

[gkya]

Elisp is a good lisp. Certainly not the best, but quite workable, and very pleasing when the environment it's in is taken into account. Emacs is open source, has better apps than Sublime,not a web page like atom and not code centric like vs code. But maybe sublime and atom could provide a similar environment as they have the tools to create parallel ones. Butnothing like org and gnus exist elsewhere, unfortunately.

[pleasecalllater]

Could you tell me what was the last problem you had that an IDE couldn't do, and vim/emacs could?

[to3m]

This happens to me in these main day-to-day cases, comparing Emacs to Visual Studio and Xcode:

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

[kazinator]

Edit a file on an ARM board, where the flash filesystem is less than 100 megs.

[dcousens]

Easy. Vim doesn't get in my way.

[lghh]

What do you mean by this?

[kazinator]

Probably that you actually get out of Vim when you're not editing anything, so it's not running at all.