5 ms·

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 di

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.

intranation 15y ago
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
heretohelp 15y ago
>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.
saulrh 15y ago
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.
julian37 15y ago
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.
- johncoltrane 15y ago
  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.
  - julian37 15y ago
    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...
    - tmhedberg 15y ago
      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.
      - 15y ago
aerique 15y ago
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.
- gbog 15y ago
  > 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.
thingie 15y ago
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.
johncoltrane 15y ago
Background compiling for better completion and as-you-type syntax-checking. IDE stuff mostly.

intranation 15y ago

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

heretohelp 15y ago

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

saulrh 15y ago

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.

julian37 15y ago

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.

johncoltrane 15y ago
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.
- julian37 15y ago
  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...
  - tmhedberg 15y ago
    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.
    - 15y ago

aerique 15y ago

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.

gbog 15y ago
> 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.

thingie 15y ago

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.

johncoltrane 15y ago

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