Gnus is an awesome piece of software and having all of Emacs editing capabilities at hand when writing mail is fantastic. I'd use it as my primary mail client if it weren't for the multithreading issue.
Not sure why you'd mock this use of Emacs, after all mails are text and as such very well suited to being composed with a text editor...
My MUA (Mutt) can launch any editor you like for composing mail. I use Vim, but it would work equally well with Emacs, nano, or whatever you prefer. Mutt is not alone in this regard.
The point is, you don't have to have embed your MUA inside of your text editor in order to use your editor for composing mail. There's nothing particularly wrong with that approach, but it's not the only way to get that benefit.
I agree you don't have to, but if the interaction gets more pervasive, such that the points of interface become many, it can be easier to just implement it in the same environment. If you just want to edit mail in vim, that's one thing, but if you want to be able to use commands in the mail editor to contextually interact with the rest of a mailbox (highlight a URL and search your mailbox for other occurrences of that URL, or add an email address to your address book, to take simple examples), it becomes more like the IDE case. Either you have to implement the IDE in the editor's scripting language (the emacs approach), or you need to call out to a number of special-case Unix tools to implement each of the hooks (the vim approach).
I write all my work e-mail in GNU Emacs and use the Emacs VM mailer.
Because it's all inside Emacs, text from other contexts -- code, shells, mailboxes, and compiler and tool output -- can be accurately and quickly pulled into the messages you compose, improving the content and reliability of what you're saying in mail.
For example, if I want to use a complex identifier from a source file I've just looked at, I can autocomplete it (M-. or find-tag) quickly from a substring. I can choose autocompletion suggestions simultaneously from all contexts.
Obviously, copying and pasting regions from those other contexts is much more immediate too.
This is in addition to the advantages of having a familiar and powerful editing tool for formatting, tidying up messages, trimming unnecessary content, etc.
> Not sure why you'd mock this use of Emacs, after all mails are text and as such very well suited to being composed with a text editor...
Vim user here. I use mutt for email (which opens vim for editing emails), Vimium for Chromium, and I've set vim to be my default editor, my shell accepts vim commands, and my tiling window manager uses vim-style keybindings.
So, I almost never have to do anything in an environment where I don't have access to all of the power of Vim... and yet my text editor remains simply that - a text editor.
No problems with multitasking, because I've never needed to do more than one thing at a time in Vim, and I can't imagine ever needing to. All of those things that you're thinking of as separate processes in Emacs are things that I delegate to dedicated programs that specialize in doing those things. But I can get all of that modularity without sacrificing any of the vim key integration.
Not trying to sell you on using Vim, but just trying to explain the different reasoning.
I wouldn't mock it, actually, but others ("fanboys") do.
I got that, sorry if my reply wasn't clear. When I said "not sure why you would mock it", what I actually meant was "why one would mock it".
Anyway, as I've argued before [1] the whole Vim-vs-Emacs (and Emacs-vs-Vim) fanboyism is sad and a waste of many talented people's time. Can't we just get along and instead focus our efforts on converting the legions of people who understand neither Vim or Emacs and embark on writing the n-thousandth Notepad clone? :-)
Not sure why you'd mock this use of Emacs, after all mails are text and as such very well suited to being composed with a text editor...