>Vim and Emacs are still superior if you want to put the time >in,

TBH, not every developer is willing to become a power user or interested to learn an IDE instead of the language itself. Being someone who worked on VStudio alot and now on Linux/Mac based tools, I can safely say that Microsoft tools are Developers friendly most of the time. It's good they are introducing same touch for Linux/OSX community.

Vim is a language to edit text and you can use that language in a lot of development environments. if you code all day it's worth learning.

verbs like ci" (change inside ") which deletes inside the current double quotes and leaves you in insert mode are pretty easy to get used to. dd deletes a line and puts it into the yank register so you can paste it somewhere. u undos an action.

using a plugin with visual studio is pretty king to get the best of the IDE and the most common vim functionality.

Classic SO answer on why vi: http://stackoverflow.com/a/1220118/1772636

edit: here is another classic why vi answer that is a bit different http://www.viemu.com/a-why-vi-vim.html

Why spend a few hours over the course of 60000+ working hours to learn how to use more effective tools?

"a few hours" ??? Come on, let's not pretend that EMACS is going to take "a few hours" to come to terms with and become more productive in than an IDE.

Actually, you can get decently proficient in just few hours. Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?

Humans have this funny thing as they grow older - they look at a thing, maybe try it out for few seconds, and then immediately determine it's too difficult and it will take forever. They rarely bother to spend actual five minutes, to the clock. If they did, they might actually have learned something.

25 minutes of deliberate practice - a single Pomodoro - is enough to become acquainted with several of Emacs features - like, navigation by semantic units and incremental search and autocompletion. You won't get proficient in that time, but it's enough to rewire yourself to actually start using it when writing code. Which will then lead to you becoming proficient while doing your regular, billable work.

Seriously, set up a Pomodoro timer, sit in front of Vim or Emacs, and try to practice a few things. You'll be surprised how fast you can learn.

(And yes, I did that, so I'm not talking out of my ass. I actually almost doubled my Emacs productivity once in 5 pomodoros - in 2.5 hours - two of which I spent watching Emacs Rocks videos, two on rewriting s-expressions with Paredit, and one on multiple-cursors.)

Actual proficiency in emacs takes time, a lot of it, and practice, a lot of it.

To reach a level of skill where using emacs is easier/faster/better than something like intelli-j (for instance) requires significant dedication and repetition.

Far, far more than "a few hours".

> Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?

Not the parent, but I've spent a significant amount of time with pure vim. I use vim bindings in everything from my web browser (vimium, vimperator) to my WM (i3 & kde vim navigation bindings), to my text editors & IDEs (atom, VS, sublime)

Despite all that, I still find using pure vim to be ineffective relative to just using Atom, Sublime, VS or whatever with vim bindings. I may have internalized the most basic navigational concepts, but the more advanced / esoteric shortcuts that are essential to use vim as an exclusive editor are still ones I need to look up - and that's not counting stuff specific to vim packages liked nerdtree.

At the end of the day I'm sure you could always argue that I should have practiced differently / better / more or whatever - but to what end? There are plenty of full featured text editors on all platforms that do everything I need. Why on earth should anyone force themselves through dedicated practice just to learn the intricacies of a 20 year old editor?

> Have you actually tried sitting in front of Emacs or vim for more than 30 minutes, to the clock?

Not parent but I have. I still would recommend something else for all the stuff I work with.

That said, it is amazing, I just believe in my line of work people are better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.

> I still would recommend something else for all the stuff I work with.

I sometimes do to. In particular, when that stuff is Java or C# - it's hard to beat the support IDEs gives you there. So I personally opt to switching said IDEs to Emacs keybindings instead.

(Also, one could argue that you need IDEs there mostly as crutches to support the weak language, but that's a topic for another day...)

> better off spending time learning an ide, esp refactoring, efficient search/ replace as well as how to enable block selection.

Refactoring - if you mean semantic transformations supported by your IDE, then yes. See above. But for search/replace and block selection no IDE beats the convenience of Vim and Emacs. They simply can do that better and more naturally (along with plethora of similar things helping with selection and navigation). And this is exactly the type of thing I was talking about in my previous comments - you can learn both under one Pomodoro if you focus solely on it, and then normal work will quickly take you to proficiency.

I've used emacs as my main text editor at work for the past 9 months, and I can safely say I am still nowhere near proficient. I'm getting better, but I can fully appreciate why emacs has the reputation it has.

I actually switched from VS to vim (while doing a project that integrated ironruby and C#). It took me about a week to reach 75-80% effectiveness with vim. At the end of 2 weeks I was back to full speed. At the end of 2 months I was considerably more effective at editing code. I'm now several years and several jobs removed from that initial project and I can't imagine not using vim.

IronRuby... good (and too short) memories.. I hope MS will embrace Ruby again sooner or later.

I gave up on that hope a while ago. And also on developing for Microsoft platforms in general.

This is completely nonsensical.

I switched to Emacs (Spacemacs) from Sublime Text with zero prior knowledge of vim or Emacs. In a day or two I could continue doing what I was normally doing. In a few weeks I felt completely comfortable.

My 13 year old daughter came up to speed with emacs in a couple of hours. Now she's starting to realize she can make it into whatever she wants and make it work however she wants. She hadn't even thought about being able to program new functionality into an application. It's opened whole new worlds for her. Yes, emacs.

You're making the assumption that vim/emacs are more effective tools.

The best possible programming environment is comprised of emacs coupled with a "lispy" language such as Common Lisp, Scheme, Racket or Clojure and the REPL to go along with it.

Nerdvana.

And the somewhat sad thing is that this is only a shadow of what was once possible on Lisp Machines... In some areas, we really did make a big step back over the last three decades.

You're arguing that stating that water is wet is an assumption

If it's so obvious then it should be easy to back up your claim with data.

I highly doubt its even possible to obtain such data. The best you will have is anecdotal claims.

For example, do productive programmers tend to use Vim or is it the other way around? It's hard to find the causality.

Because I don't need them, and would rather focus my attention on the part of the job I actually care about. The simplest tool which doesn't waste my time is the best. I have found that I would rather use a simple editor with no features that I never have to think about, and automate repetitive tasks using the same tools I already use for automating repetitive tasks: programming languages.

That just sounds like a self rationalization to me. "I don't need them" is something you say after you tried something and realized you actually don't need them. It doesn't carry any weight when you haven't even tried. Because when you do, it's just saying you don't want to try new things. I'm not saying you must learn these, I'm just saying you shouldn't lie to yourself.

That's a little harsh, but the cognitive bias you're describing certainly is a common one, and it's one I struggled with a lot when I was younger. I've learned to manage feelings of fear or anxiety by reinterpreting their activated, buzzy feeling as excitement or anticipation. This works well, though it has turned me into something of a daredevil...

I really don't think that's what's behind my attitude toward code editors, though. I've been writing code for thirty-odd years and making a living at it for twenty-five, and I've spent the majority of that time working on dev tools. Compilers, mostly - but I've written a couple of editors, too, plus a debugger, a couple of linkers, an assembler, you name it. So I have had a lot of time to think about tools, and have been lucky enough to get several chances to put my ideas into practice.

I'd have trouble remembering the names of all the different editors and IDEs I've used over the years. Emacs and vi are ubiquitous now but that was certainly not always true, and on some platforms, particularly embedded environments, using anything but the officially-blessed toolchain can make your life unnecessarily difficult. I have learned to get my work done using whatever tools happen to be on hand. That's meant a wide variation in the kinds of features which are available, the specific control-key bindings, the details of the build environment, pretty much anything you can imagine - so I have learned to rely on the basics and ignore the rest.

I find it far more frustrating to deal with a sophisticated tool that isn't working quite right than a simple, brainless tool that does the job but requires a little extra manual labor.

I'm not here to play with editors, after all, I'm here to build software, and the editors are just a means to that end. Time spent learning sophisticated editor features has to justify itself in time reliably saved using those features, which has to be balanced against the time wasted when they don't work quite right or when you have to go dig through the documentation to remember how to use them, times some distraction multiplier for the fact that you're thinking about the tool instead of the job you're using the tool to do. In my experience, there's been too much change and not enough actual need for sophisticated editor features to justify their cost.

Even if a sophisticated editor could allow me to perform certain editing tasks more quickly, that wouldn't change my overall productivity very much at all, because I spend far more time reading and thinking than I spend typing or editing. I type fast enough already; it's my brain that needs to be accelerated, and the best way I've found to do that is to eliminate distractions and focus as much as possible on the problem I am actually trying to solve.

I wrote a simple terminal-based editor a couple of years ago, including all the features I use every day and none that I don't, and I've been using it for all my daily programming work ever since. It's an unabashedly personal expression of my own taste, so I wouldn't necessarily recommend it to anyone else, but I like it and feel good when I use it. It's nice to know everything there is to know about the tool, so that I never have to think about it or try to remember how it works. Perhaps some day I'll be working in some new environment with some new toolchain and I won't be able to take ozette[1] along with me, but that's fine - wherever I go, I'll be able to get my work done with the tools I find there, because I'm comfortable doing my job with the basics.

1 - http://www.github.com/marssaxman/ozette/

So... you'd rather spend the time writing new code to do repetitive tasks rather than use existing ones? You'd rather spend time writing 'search and replace' in your favourite language than just use an editor with it? I don't see how that doesn't waste your time.

I'm happy to spend a little extra time every now and then doing some unusual task by hand in exchange for never having to think about the editor or try to remember how some powerful, infrequently-used feature works. As long as the editor can do everything I want to do on a daily basis, I'm happy; if it can also automate tasks I only have to do every week or two or every couple of months, it's a waste, because it'll take some effort to remember that the feature exists, what it's called, where to find it, and how to use it. I'd rather just use a simpler editor and deal with that oddball task in whatever way is convenient when it comes up. Since I spend all day slinging code, bashing up a little script to do some odd code-munging job is no trouble; I already have all the tools I need to do that paged into my working memory.

I was thinking more of the sorts of automatic refactoring tools some people really like to use in their IDEs. I haven't found that such tools save enough time to be worth learning how to use them.

That is fine, I think it is great that IDEs exist for easy editing and debugging. But power users will always exist in the programming community. These people will naturally use Vim and Emacs because they support the customization levels needed for complex programming workflows.

In my experience novices have an easier time learning programming with an intuitive IDE, but experienced users use whatever makes the most sense given the task at hand, which in many cases might also be an IDE. They're just different tools with different pros and cons, and each of those pros and cons are weighted differently depending on what you're trying to accomplish.

Very few programming workflows are so complicated that it is simply not possible to do something without first creating your own highly customized environment within Emacs. However, very, very many programmers do have a lot more fun screwing around with customizing their work environment (editor, window manager, shell, etc.) than using that environment to get actual work done (myself included).

Which is not to say that Vim and Emacs aren't awesome tools, I just wouldn't generalize anything about anyone based on the tools they use.

One thing that is not immediately obvious about vim (or evil Emacs) is the gamification part. Before I switched to Spacemacs myself, I used to think -- why do those vim guys torture themselves using an old deprecated tool. Now I actually find it fun to edit text or code and think of how much everyone else is missing :)

It makes sense that if you program a lot that you will learn how to save time in the long run. It took me a day or two comfortable enough to be efficient in it, at least as I was with Atom. After the first few days, you will just learn new tricks while you are programming.

You will see that after you learn how to use Vim you won't want to use anything else to edit text, you emails, browser and word processing will be in Vim.

> I can safely say that Microsoft tools are Developers friendly most of the time

You only think that because you have used it and became accustomed to vstudio. As someone who has used vstudio, eclipse, atom, intellij, vim, emacs - I can safely say that vim and emacs are far more 'developer-friendly' than the others.

Why?

Because the low-level modularity of Vim and Emacs gives you more control, by letting you choose the combination of tools you use ; instead of tying together the language(s), the compiler, the tag/completion engine, the build/project system, the debugger, the profiler, like many IDEs do.

The sole concept of IDEs specialized for one language makes me cringe.

I am a long time Vim user but I have never ever managed to get c++ tag completion work consistently there. At some point I just stopped trying - went to Qt creator and turned on Vim plugin there. The experience (for C++) is just vastly superior. The IDE integrates with CMake natively, the debugger is graphical and works, the symbol navigation over all project is blazing fast, I have real refactoring etc...

I still use Vim a lot, for JavaScript, for text, for remote sessions... But when a tool with real semantic highlighting and understanding of code is available (with a Vim plugin) then I'll take that.

Check out https://valloric.github.io/YouCompleteMe/ C/C++ completion for VIM.

Of course an IDE like QT Creator does many things better. But it's a tradeoff always.

> The sole concept of IDEs specialized for one language makes me cringe.

Can you explain this a bit? I don't see that Sublime, VS Code, Atom, etc. were made for one language, at all. As a little background, I've used vim for a while, then switched to Sublime Text, and am just trying VS Code. I find Sublime/VS Code/Atom to be far easier to customize than vim.

This is not what I said: I consider Atom and Sublime Text to be advanced general-purpose text editors, not IDEs.

I was indeed referring to Eclipse and Visual Studio. From what I observed around me, for some reason, people don't use these to edit:

- shellscripts/perlscripts/batchfiles.

- Files written in a in-house domain-specific language.

- Configuration files.

- Makefiles and project files: vcxproj, sln ...

Actually, I observed that these kind of IDEs discouraged people doing the above things, giving them the impression that it's not "real development" (I suspect that this is, in part, where the bizarre term "scripting language" comes from, but this is another debate).

I'm pretty sure he is referring to Eclipse, Visual Studio and the like.

That's what, gone are the days when we'd spend hours and hours to learn the little little ways of vi and the myriad functions in emacs. Now we need to get things done, can't afford to sit down and study the entire functions of vi and emacs. I don't mean to troll but after switching to vscode and the go plugin I learned go webdev and wrote this small intro book, http://github.com/thewhitetulip/web-dev-golang-anti-textbook...

That is the power of vscode, it provided a good enough way to play with code, yes not outright innovation, but an awesome text editor nonetheless.

Atom has a great Go plugin: linting, context aware completion, fixes code style on save, etc..., all powered by Go's command line tools.

I'm not saying Vim and Emacs are the be-all (I program mostly in R, so RStudio is my main tool), only that VS Code hasn't changed anything fundamentally. It's just a good editor.

Sublime Text has GoSublime as well.

What, exactly and without sweeping generalities, does it do that is a transformative step over Sublime Text or Atom?

Or, hell, even Kate?

For example the Git integration is awesome and even better than Atom's (you can commit, push, ...).

Of course you can do a lot with extensions, but at least in Atom's case they break a lot for me.

Well, okay, let's talk about that. Is having source control in your text editor enough of a benefit to one's daily routine as to be a step change of productivity or quality of life? It may be for you and I'm not saying you're wrong for that, I'm asking because it isn't for me; I have an alt and a tab key.

Bear in mind that the claim wasn't that it's better in some ways, but that it's sweepingly better than the stuff that came before (and Atom wasn't even mentioned by the OP, which is funny--I mean, I don't use it, but it's obviously in the conversation).

"Well, okay, let's talk about that. Is having source control in your text editor enough of a benefit to one's daily routine as to be a step change of productivity or quality of life?"

Uh, if you edit tens or hundreds of text files per day, it's a game changer.

Being able to press ctrl+K instead of alt tab -> write "git commit -m" is pretty nice and much faster...

EDIT: that's only the most trivial benefit of git integration

Having the git diff in your editor gives you syntax highlighting and let's you edit it (the right side) like you're used to.

I guess the killer feature of VS Code is multiple cursors (Ctrl+D). I only know of Sublime Text and Atom who also have this feature on Linux, not sure about Kate. Sublime Text is closed source and not gratis, Atom is slow and buggy.

Not allowed to reply to your post, so replying here.

No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.

That they are not built-in really doesn't matter though. All these editors revolve around plugins, and it's common practice to save your preferences on github or the like so that it's easy to use the same settings and plugins on every machine.

> Not allowed to reply to your post, so replying here.

I think you have to wait a few minutes, then it gets activated.

> No, not built-in. They both have plugins, and allow you to set the key shortcut to whatever you please.

That's too complicated for me. Last time I've tried to set up vim and emacs to my liking it was a mess: A lot of copying and pasting around random code, changing configuration files I didn't understand, ...

In all respect, but you are presumably a software developer. If someone approached you saying that language x is a mess, as they've copy-pasted around random code and changed configuration files they didn't understand. Would you accept that as valid criticism or told the person to actually learn their tools?

Granted, Atom, Sublime, VSCode etc. are easier to start with because they expose customization through JSON files instead of a custom programming language. But if someone where to tell you that they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).

If you know your editor, adding functionality like multiple cursors is easy. The greatest strengths of extensible lightweight editors like VSCode and Emacs, is that such functionality is only a package away.

> they didn't understand how multiple cursors worked in VSCode, you would tell them to learn their tools and send them a link to the relevant page of the documentation (if that).

No that's the thing: I would tell them to press Ctrl+D, simple as that. Multiple cursors in Sublime Text, Atom and VSCode are intuitive and it's the first time in an editor that I actually use them.

Emacs and Vim also have multiple cursors.

Built-in? What is the equivalent of Ctrl+D (Sublime Text, Atom and VS Code) in vim and emacs?

For me it does, depending on the project. (Using emacs/magit, having a dedicated buffer just for magit.)

I want to keep on top of my current branch, what is untracked, what is unstaged and staged, quick diffing, etc. It actually helps a lot with productivity since I don't have to actively query for this information when it's all in one screen.

If I used another editor, I would like to have similar features. Maybe it can be done, but I am quite fluent in magit already, and one major thing keeping me from moving to another text editor for my current projects (if it actually mattered.)

This is something I really do not understand. I can switch to my terminal, build, run, stage, commit, push all in like 5 seconds. As well as anything else I need to do in the terminal.

The only 'plugins' I use are a keyboard shortcut (cmd+space) which puts me in a terminal window and rupa/z[1] for jumping into a project directory.

[1] https://github.com/rupa/z

Let's say you look at `git diff` and notice something needs to be changed. What do you do now? You need to quit, open the file, find the line, do the change, save and quit. Now you need to reopen git diff and scroll to the old position. This all takes a lot more than 5 seconds on the terminal.

Another scenario: You type `git status` and see a file called `src/a/very/long/path/file.c` hasn't been staged yet. Now you need to type that file path for git add or git diff. Takes more than 5 seconds, but it's just a simple click on a + symbol in VS Code.

1. atom is slow and clunky it hangs when I paste a 10000 line sql insert statements 2. sublime text: sorry didn't try

vscode's benifits:

blazingly fast modern design works on linux/mac too little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.

It is a great way to code if you don't want or can't use vi/emacs, I don't have the luxury to learn all the nook and corners of emacs, I started using Go plugin in vscode and today I have built go apps and written partially completed book: http://github.com/thewhitetulip/web-dev-golang-anti-textbook...

i tried giving vi a chance, but nope. couldn't bear it for more than a day, large webapps require a UI IDE, vscode > everything else I tried till now

> blazingly fast modern design works on linux/mac too little features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there.

Literally every other popular code editor supports some form of "go to symbol".

"Some other go to symbol" It is obvious I didn't use intellij and pycharm and stuff like that, but the ones I did use, kate, gedit, eclipse, notepad++ didn't let me drop into a function "With ease" yeah you can use that feature in eclipse, but it isn't with ease, maybe it is because I am so biased for vscode. We'll never know, but the thing is I feel productive typing into vscode than I ever had with some other editor I tried.

Go ahead and downvote it, but after all every programmer worth his/her salt does realize that the choice of IDE/text editor is ultimately a personal opinion, so long as you as a person are comfortable using it, that is good for you, it does not make a tad bit of difference to anyone else in the world.

I downvoted you for your brutal incuriosity, not for your opinion.

> features like ctrl+P which lets you to jump to functions rather than play with files, I didn't know any other editor which allowed this feature to be there

IntelliJ

> Vim and Emacs are still superior

I think the parent was talking about modern text editors such as Sublime, Atom, Brackets etc.; Vim and Emacs are completely different beasts (note: I love both).

Within the category of modern text editors, VS Code is in my opinion revolutionary in several ways - I will give you three examples

The first feature that I find "disruptive" is the way VS Code offers a standardised interface for debuggers, hence debugger plugins are much easier to create - and you can see that VS Code already has debugger plugins available for many languages: https://marketplace.visualstudio.com/vscode/Debuggers?sortBy... the availability of such plugins for Atom and Sublime Text is not nearly as good.

The second aspect where VS Code changed the game is the clever way it leverages Electron (the framework it's made with, Atom is made with Electron too) - while creating clever workarounds to known Electron bugs - e.g. VS Code, unlike Atom, does not suffer from this bug https://github.com/atom/atom/issues/10720

The third aspect is the git integration - since Atom is sponsored by Github, you would think it has the best git integration out there - but VS Code has gone the extra mile by giving you a great user-friendly UI interface for staging and committing (yeah, I know, anything more complicated than git add -A requires the command line - the fact is that nearly 50% of all the git commands I type are git add -A, LOL).

PPS I totally agree with you about the importance of tooling. But e.g. if you have a debugger that does not have an interface to your editor it becomes hard to set breakpoints. So the editor needs to integrate with your tools and VS Code is great at that.

"Vim and Emacs are still superior if you want to put the time in, and both have non-terminal interfaces."

I don't need an instruction manual to figure out how to close VSCode.

You also won't need an instruction manual for a lot of other things, because you won't be able to do them at all.

It's open source, I could do it.

Oh but that's needlessly hard and annoying? Well so are Vim and Emacs.

>> and both have non-terminal interfaces.

> I don't need an instruction manual to figure out how to close VSCode.

To close GVim, you click the 'x' in the upper right/left corner, like any other window.

To close the GUI Emacs, you may just click the X as well.

True, how did I forget?

In Vim, pressing Ctrl-C (which is how you usually terminate a console application) tells you to write :quit<enter>.

Alternatively, you could just close the terminal window.

And how do you install extensions for GVim?

You put extensions into the proper folder, or use a tool like 'Vundle'. Yes it's slightly more difficult than using Atom, but anyone who can use a tool like Git or Cmake should have no problems figuring it out.

So, as a 20 year user of emacs with a .emacs file older than some people who post here: I have moved away from both.

I like being able to use other languages for editor extension, having a competent graphical and text layout layer with image support, and quite frankly I find emacs development tedious now.

So... Do I need a few more years of time to "get it?"

What I meant was that if you don't have the time or inclination to learn the myriad ways of vi and emacs, there isn't a really great light weight fast text editor, eclipse is too damn slow. so beyond eclipse, there is this great text editor which has great design. we never had the great ctrl+P option in eclipse as far as i can remember where you can jump to definitions, say I have a 100 files project and I want to change the GetUseFunction then I ctrl+P and type the function names, it tells me all the function names and lets me go to the function name directly.

I am not aware if that feature is available in other editors, I tried light table for a short time, but it isn't getting much attention since they are working on some other product. ctrl +P transformed the way i write go code, now I dont' have to bother to remember which file stored what, just ctrl +P function name, as i know what all functions I am using or I can just scroll!

Ctrl+P was taken from Sublime, which in turn took that from TextMate. I think.

VSCode and Atom are essentially just Sublime Text with Javascript instead of Python as the plugin language. Also, IntelliJ has had this for quite some time, though it doesn't meet the criteria for light weight text editor, it is certainly better than Eclipse.

While I do agree that VS Code is nothing revolutionary, suggesting Vim and Emacs are superior at this day and age makes no sense. Becoming effective at using these editors is very hard and not practical when there are so many other things any engineer worth their salt has to worry about. Most plugin systems for these tools are a nightmare. Vim has about three or four different plugin solutions and they all have different caveats.

While I agree with regards to Vim, I don't really see how Emacs is hard and impractical. It doesn't have modal editing, you just open a file and write, and the plugin system is built-in.

I do, however, agree with you. Mostly because you can customize Atom and VSCode to have all the same benefits as Emacs and Vim. Except for running them in the console, which I know some people like having the option of doing.

I used emacs as my primary editor for 22 years but switched to clion last year for c/c++ development and am thinking of switching to pycharm for python stuff.

I still use emacs for quick editing, moderately complex search-and-replace in limited numbers of files (for when I don't want to bother with perl), and a handy scratchpad for throwaway things, but I don't intend to do a lot more software development in it anymore.

Compared to Vim's learning curve, the Wall from GoT is just a small speed bump. I have tried to learn vim for 10 years now and just cannot get past the initial stages.