Hacker News Reader

Comment by einhverfr | Hacker News Reader

I enjoyed the article, even though I am a VIM fan. Many of the same advantages apply to VIM too.

At the same time I thought it was also like looking into a different culture. "Easy" meaning "copy and paste what a user tells you?" I guess there is a different view of easy.

The disadvantages struck me as rather interesting. 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. Is it about running a compile job in one buffer while editing in another?

I also noticed a big reason to use VIM or EMACS over an IDE that seemed missing and that is that both these editors have tons of features for gracefully editing large numbers of large files. The IDE's I have worked with haven't come close here.

For now I will stick with VIM, which I feel comfortable and confident on. However, seeing folks talk about the benefits of the other is interesting.

View on HN

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.

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.

Multi-threading is asked for because when you run a complex thing in a single buffer (i.e editing something over Tramp mode, compilation, magit doing Git operations etc.) it can block the editor.

Hence, multi-threading is a potential solution to that.

Edit: spelling

Contrary to how Vim is usually used Emacs users tend to start only one Emacs instance and spawn multiple windows from that. This is because using a single Emacs session has certain advantages (completion, searching buffers, start up time (mostly a thing of the past now), etc.).

However one disadvantage is Emacs not responding when it is busy with something else, like f.e. someone else mentioned Gnus retrieving mail. It doesn't happen often but it is annoying. I tended to use a separate Emacs instance for Gnus in the past.

> Contrary to how Vim is usually used Emacs users tend to start only one Emacs instance and spawn multiple windows from that.

I have seen new vim users opening multiple vim sessions, and copy from one to another with the mouse, and mess the indenting, etc. Experienced user would open one instance instead.

Multithreading would be a great feature, working with an editor where the whole UI tends to block itself on some network (tramp or via sshfs/nfs) operations is unpleasant. It's also a sign of its age. I also miss, for example, UI localization. You can, of course, have everything hardcoded in English, but it's a limitation. Well, whole UI is dated. In (g)vim you can have nice pop-up code-completion, in emacs, it's not that nice. The UI is very dated, sadly.

Background compiling for better completion and as-you-type syntax-checking.

IDE stuff mostly.

  I am not entirely sure why you need multithreading in a
  text editor for example.

I can see a few uses for it. The big one for me is semantic analysis. Intellisense is a surprisingly large computational burden, for a single example, and moving it and things like it off the thread that's handling your UI is probably a good idea.

>I am not entirely sure why you need multithreading in a text editor for example.

People often interact with APIs in Emacs or with things like git repos. Being able to make non-blocking calls to HTTP APIs and such would be rather nice.

Reply on news.ycombinator.com