Hacker News Reader

Comment by julian37 | Hacker News Reader

I am not entirely sure why you need multithreading in a text editor for example. Perhaps someone could enlighten me as to when this sort of thing would help.

Basically, the lack of multithreading prevents any sort of background processing (unless it can be implemented using an idle hook, which often isn't possible.)

For example, Gnus (a newsreader which can also be used to read mail from a POP or IMAP server) locks up Emacs while it is checking for or fetching new mail. This is quite painful when fetching mail over a slow line or from a slow server, and causes people to do hacks like mirroring their mail onto a local IMAP server from where Gnus can fetch it more quickly. But even then, there is a noticeable pause when the server is accessed.

View on HN

The example you give is the typical Emacs feature Vim zealots like to mock.

If I want to read an email I simply switch to my email client, thus virtually eliminating (almost) all risks of Vim/Emacs crashing.

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.

I could, but wouldn't want to, live without it.

+1 for vim + mutt!

I wouldn't mock it, actually, but others ("fanboys") do. Often.

You are right, emails are texts. Managing emails and contacts and calendars can go (and usually goes) well beyond text editing, though.

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? :-)

[1] http://news.ycombinator.com/item?id=2037133

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

Well, considering that Emacs is supposed to integrate smoothly with external processes, it looks that asynchronous IO support it will be a better solution. Multithreading is generally a tricky business for interpreters and virtual machines.

So to reduce editor interface freezing, looks like a dead-end: either you expose asynchronous IO (like AJAX), or you add the complexity to have a multithreaded interpreter (like JVM) or implement a sane concurrency model (like the actor model in the BEAM machine). Or else avoid Emacs modes that are known to freeze.

However, I recently discovered that VIM uses threads:

  $ ps -eLf | grep vim
  UID        PID  PPID   LWP  C NLWP STIME TTY          TIME CMD
  etanol   15073 15023 15073  0    2 22:23 pts/2    00:00:00 vim
  etanol   15073 15023 15074  0    2 22:23 pts/2    00:00:00 vim

I wonder what for :-S

Unfortunately integration with other processes does not always lead to the expected results and many tools have been reimplemented in Emacs Lisp to integrate better with the rest of the Emacs platform. Suddenly, not having multi-threading becomes a real issue (Why the heck is Gnus taking so long and why can't I edit in the meanwhile?).

Some might say that it is insane to use Emacs for every conceivable task, but it offers me exactly the degree of integration I'm after, a uniform UI and a disruption free environment for most of my computing needs.

Reply on news.ycombinator.com