Great idea, vim is intuitive ( -ish?) once you understand what each character means ( y for yank being a simple example ). If anyone is looking to learn vim or any IDE really, check this place out.
https://www.shortcutfoo.com/app/dojos/vim
It seems to me there is a lot of VIM vocabulary that is very different from what is common on the desktop today. I don't know what yank means. I don't think I have a desktop app that has a yank function.
The current front page example is using 'z' to "redraw the cursor". I know what all those words means, but put together they are complete jibberish. Looking at the gif, it appears that redraw is VIM-speak for scrolling.
Also "z doesn't do anything on it's own. But it pairs with a number of other things. It is used for redrawing the screen, saving and quitting, as well as manipulating folds." doesn't sound intuitive at all.
As a Vim user I would agree with what you've said. I would add that a lot of the terminology would have made more sense back when it was introduced, and at that time the other now-common versions weren't nearly as common. I think an effort to use both the Vim terminology, and the common terminology that people would be most-familiar with would be good. If it said "yanking (copying)" and "redraw the cursor (scroll the screen relative to the cursor)" it would be obvious.
Also, I think `z` is a fairly bad example, because nothing really starts with `z` and in some ways it's just a hodgepodge of different things that needed keys (`z` is of course not the only key like this).
`y` for example is used for everything related to yanking. `p` for everything related to pasting. `i` for insert mode. `v` for visual mode. `c` for change, `d` for delete, `w` for word. There's other various examples I'm sure, but most of the basic usage of Vim (besides, perhaps, `hjkl`) all maps to fairly easy to remember keys once you do it a few times and understand what they stand for.
I did VIM Adventures. Then I installed VsVim for day to day work. A while later, it just makes sense. I'm so fast, it's like magic. Vim macros alone make it worth it.
At any rate, I never spent much time memorizing keys. I'd look up a thing or two, apply it, and it'd just sink in.
And that's not a bad thing. I don't think it's right to call Vim intuitive unless you're used to reading a book to understand 35% of the features of an editor.
But Vim isn't about being intuitive, it's about being efficient. Once it 'clicks' you will be able to express incredibly complex text manipulations in only a few keystrokes. And with configuration you'll build the most powerful but comfortable environment that you'll miss anywhere else.
In other words, Vim is a professional tool, not a toy for causal user. It offsets steeper learning curve for much more powerful and efficient way of editing text. It's a feature.
> It seems to me there is a lot of VIM vocabulary that is very different from what is common on the desktop today.
The operating word here being "today". Vim - and Emacs - are relics from the era when computing was much more saner than it is today. They're old, older than most of us here. It's not that hard to learn their vocabulary once you understand all those words are not weird, it's how things were called back before the industry did another circle and reinvented some wheels again.
Not really. Unix is the archetypical virus on the history of computing. Whether a cause or just a symptom, it's part of the problem of the current state of computing industry.
I've never liked the term yank, to me it means take something out of there. But it's really "copy this into a buffer," for use later.
That said, I had my annoying fifteen seconds when I first learned it, then just used it as intended. Honestly, my fingertips do the how-to thinking these days, and my brain does the what-I-want thinking.
I see yank as copy but with a history, like a copy plus undo/redo state. Because that's how the functionality was introduced to me with Vim. I can cycle through previous 'yank' buffers, yet on my OS I'm limited to a single 'copy/cut' buffer so I remembered them as distinct terms.
of course vim isn't intuitive. it's extremely hard to learn, cryptic, confusing, and in some cases deliberately obtuse, but is very fast and powerful once you've learned it.
i don't evangelize vim at all. it's a very difficult tool used only by people who need its functionality and have the patience and intelligence to learn it. don't like it? not sold? then don't learn it. use something easier.
It seems to me there is a lot of VIM vocabulary that is very different from what is common on the desktop today. I don't know what yank means. I don't think I have a desktop app that has a yank function.
In most Unix systems you should be able to go to the beginning of a line, press Ctrl-k and then Ctrl-y to yank. At the very least your browser and terminal should understand those two commands.
I feel like emacs is the same way. All the talk of buffers, kill rings, yanking, etc always threw me off. I'm used to it now but I feel that audiences that are used to Windows/Mac style 'normal' text editors probably bounce hard off of vim/emacs pretty often because of the different way of doing things.
Hard to fault Emacs for that. It's older than Windows, it's older than the IBM convention of CTRL+C / CTRL+V. And older in this industry usually doesn't mean worse.
What!?! vim is the most unintuitive application I have ever used. Having to understand that y means yank (and then what yank means) is one of the very reasons it is not intuitive. it's like the masonic editor, don't know the right handshake or password you don't gain entrance to productivity.
> vim is intuitive ( -ish?) once you understand what each character means
That is a much different statement than simply saying "vim is intuitive", which is the statement it appears you're arguing against. I doubt there's anyone in the world who would attempt to make such a bold claim as that.
I've found the "vim is intuitive once you understand what each character means" claim to be pretty accurate. Before learning what the keys did, it seemed like a laughably impossible-to-use program, but after learning what the keys do, it feels very natural and composable. Sure, some of that is due to muscle memory, like hjkl for movement, but a lot of that are things like "p for paste", "d for delete", "n for next", and so on. Those, to me, seem like very intuitive mappings.
That it can be "intuitive once you understand what each character means" seems a bit oxymoronic to me. A design is intuitive or it isn't. That you can figure out a complex and cluttered design and use it to your advantage over time by trawling through manuals and guides doesn't make it intuitive. Your intuitive understanding of the design may improve, but that applies even to the most brain breaking concepts, so it's hardly a useful way to look at it.
Well, some basic commands would be intuitive but aren't anymore, because most applications use very different keys or because our vocabulary changed. I.e. y(ank) and p(aste). However, once you know them they do make more sense then ctrl-v for paste (was that chosen because v is next to c on the keyboard?).
What I think becomes really intuitive once you understand the basic commands however is the combination of them. If you know that 'dd' deletes a line, it is very intuitive to me that '4dd' deletes 4 lines.
Others have explained it better in threads near this one than I could, but the short response to this is that intuitiveness is personal and contextual.
Sure, it's personal to some extent, but have you ever seen anyone sit down with a Vi/Ex/Ed-like for the first time and intuitively figured out how to work it?
It's also contextual for sure, but for the word to be meaningful at all in a UI design sense, one surely must draw the line somewhere before the required context is to know the editor from experience or by having studied its documentation. Otherwise it's an absolutely useless thing to point out for the sake of discussion. Anyone can use complex things intuitively given some exercise. That doesn't make things like theoretical physics particularly intuitive in themselves.
vim has an initial hurdle of being extremely unintuitive. But once you start learning the vim "language", you find it builds on itself and intuitiveness increases a lot.
For example d is the delete command and w is the "move by word" command, so dw is "delete word". / is the search command, so /foo searches for the first instance of foo in the document. You can intuitively figure out that d/foo is "delete everything until the first found foo", and that is exactly what it does.
You wouldn't think that if you used vim. I don't want to turn these comments into a vim tutorial so I simplified it a bit. But in the framework of vim, d/foo and what it does is totally intuitive and easy to figure out on your own. With vim when you learn a new command it applies to all the movements you know and vice versa.
EDIT: rereading my comment, I should have said "/foo moves to the first instance of foo in the document" to correlate how / is a movement just like w is a movement (w is "move by one word")
>EDIT: rereading my comment, I should have said "/foo moves to the first instance of foo in the document" to correlate how / is a movement just like w is a movement (w is "move by one word")
I find it somehow odd that often many people equal good UI with easy to learn UI. They _can_ be the same, if we have an application that is rarely used more than once, but for an application that is used often and a lot, they typically seem to be very different animals. Notepad has probably the easiest UI to learn while being as probably the crappiest text editor for any serious use with any significant installation base ever created. Vim is the other way round. It is extremely easy to do something with data using Excel. For any serious data management you are doing much better working with a database.
"Intuitive" is anything that happens to fit into the preconceptions you have. Vim is older than most software you've ever used, therefore seems unintuitive. If you were born 20 years earlier, it would be perfectly intuitive to you.
Understanding what each character means isn't necessarily the goal, however. They're the basic words and commands to manipulate text, but really you should be learning how to speak to Vim to get it to do what you want. You need to string together multiple words to make a sentence sometimes. Vim lets you do that. If you're not willing to take the time to do this: you're right, Vim isn't for you. It definitely takes more effort and practice than a lot of other editors.
Intuitiveness becomes more clear once you realize you need to learn the language to make things intuitive.
You can't just start speaking Spanish to someone and expect to get them to do what you're asking if you don't know how to speak Spanish, yet. You can poke and prod at words here and there (memorizing what each character means) but you still aren't very effective at that point. Can you ask where the bathroom is? Sure. But can you effectively tell someone where the correct bathroom is? Probably not.
"I want to yank those two lines, paste them over there, select them, and replace all instances of 'foo' with 'bar'."
Vim:
> 2YjjpVj:s/foo/bar/pg
Like speaking other languages, there are a number of ways you could tell Vim to to do what you want.
Now let's look at other editors when you want to tell it what to do. Other editors:
> Remove right hand from keyboard and put it on mouse
> Move cursor to appropriate position
> Click the button down, and drag it until the two lines are highlighted
> Crtl+C
> Move the mouse cursor
> or move your right hand again to the arrow keys
> Ctrl+V
> Ensure your text is still highlighted in some way
> (May require repeating previous steps)
> Ctrl+F or Ctrl+R or something, depending on the app
> Get into one box and enter "foo"
> Get into another box and enter "bar"
> Ensure you have selected "selected text" so everything doesn't get replaced
> Hit <enter> or click
The infamous Stack Overflow answer, "Your problem with Vim is that you don't grok vi," is an oldy but a goody.
Of course, if you expand every input out to a full line, it's going to look worse than a string of keypresses. However if we compare more fairly:
vim: 2YjjpVj:s/foo/bar/pg
Sublime: ^L^L^C↓↓^V↓^Ffoo<Esc>^Dbar
(This assumes there are only 2 instances of "foo", but you'd just have to press ^D a few more times otherwise.)
And sure moving your hand to ↓ takes slightly more time, but it's still no where near as bad as your screed makes out. And if you really care, you can make new shortcuts for movement (by editing a simple JSON file).
Personally, my experience is of using vim for several years, and then becoming approximately as proficient in Sublime in a matter of weeks, and then much more productive in a matter of months. And sure, I wasn't putting that much effort into learning vim, but then, I wasn't putting that much effort into learning Sublime either.
I would say it's faster since with 2Y you have to lift your finger off the 2 before you can press the Y, but with ^L you leave your finger on the ^ while you press the L so it doesn't even really count as 2 full key strokes. (not to mention you have to press ESC half the time in Vim to even get to the mode where "2" is what you want to do)
I usually use Sublime but when I'm ssh'ed to a machine I use vim, so I have some experience. I find that I need to exit insert mode to run commands about half the time, or maybe a little less than half the time, in order to run commands. Maybe thats just due to the type of thing I usually edit though. I don't have enough vim foo to know how to do this, but maybe you do: can you record a session and see how often you pressed escape? I'd be interested to know how often various people press escape.
We press escape a lot, many even map it to something more convenient like caps.
The point I was making though is that with vim you don't exit insert mode to run commands, you enter insert mode to write text and then immediately exit to normal mode.
It may sound pedantic, but it's a core part of understanding vim. Insert mode is the mode you should spend very little time in.
I suspect vim users don't notice because they instinctively press Esc as soon as they're done using insert mode, so they don't think of that as part of the next command. And I think that's fair tbh, it's just something your fingers do while you're thinking about what to do next.
Just want to plug that it's worth the money. I mastered all sections of the vim course and it has definitely proven me useful over the last year. I don't normally develop in vim, but IDEAVim for Intellij products seems to be enough functionality to make me happy. Just remember, it takes consistency, lots of consistency.
Hmm I disagree. At first it isn't intuitive, then it becomes intuitive after practice. I think what the commenter meant by "once you understand" is "once you have practiced." Sort of like how skiing becomes intuitive but isn't at first, or such.
That's not what intuitive means, especially not in the context of a UI.
> At first it isn't intuitive,
Then it isn't intuitive. An intuitive UI is one that requires little to no instruction because it just works and is discoverable naturally, vi/vim are exactly the opposite, they are the most unintuitive UI practically ever invented. There is nothing remotely intuitive about vi/vim. The barrier to entry is huge and is the main reason people don't use this editor.
> Sort of like how skiing becomes intuitive but isn't at first, or such.
Skiing isn't intuitive either. Getting good requires practice, that you had to practice it to get the feel for it means exactly that it isn't intuitive. Once you're good, it's not because it's intuitive, it's because you practiced and taught yourself new muscle memory.
No one is said vim is an intuitive UI, or whatever. It's simply the conditional like A => B, where A is "you know what c, a and w" mean, and then B is regarding another feature that becomes intuitive once A is true. Pick anything that you think is intuitive and I'll show you a prerequisite for it, and some times that prerequisite is sort of "bootstrap human knowledge" like "touching things that move."
For a moment, try stepping away from the semantics of what 'intuitive UI' means as a holistic thing, and think of it this way: when you read an angry letter from someone, you are immediately flustered, or something. This happens intuitively. But it only happens if you already know how to read the words and what they mean. It isn't intuitive if you don't know the language. Intuition is perspectivized and based on prior context, etc. The human using the tool is defined by their history, stuff like that. The commenter is just saying, the way I see it, given X in the history of the user, where X is "understands what each character means" (this is now assumed as part of the user's identity), that some other aspects of the entire vim-as-a-text-editor process becomes intuitive.
Yet another example is, an app meant for musicians, like Ableton, where some things are intuitive because they have rhythm and/or melody knowledge or know what filters are, but isn't intuitive if they don't. It's a spectrum. The most interesting questions are often about such nuance. Vim is interesting, and it has stuck around.
I don't know, but I personally care less about semantics than about the human-processes that actually result from the way programs are. Call it 'intuitive' or not, what do you see actually happening? What I see is people making really quick edits (I often see this in myself) that I can't do in other editors that I am able to do as an extension of myself sort of the same way I feel about playing percussion in a band.
> No one is said vim is an intuitive UI, or whatever.
Yes actually he did say vim is intuitive; don't tell me no one said X when they very well did say X.
You're failing to understand that I perfectly well understand what he's saying and I'm objecting to the use of the word intuitive; yes, that's semantics which I care about.
I don't need to take a step back or look at it another way because I'm not confused by his message, I'm objecting to his vocabulary. If that doesn't interest you, that's fine, move along. But it interests me because I'm pedantic and I enjoy discussing how a message is conveyed as well as just what's being conveyed. Just because you don't care about semantics doesn't mean others don't. Semantics matter if words are to convey meaning and every reply to a post doesn't have to share what you value about the post. If I want to debate the semantics of a word with the OP then I damn well will and it's not your place to come along and tell me I shouldn't, nor tell me I need to see it another way.
reply to OP below: As you admit the point is debatable, then you can't question my debating it. I understood your intent as well, so what, I wasn't questioning your intent, I'm questioning your choice of words to convey that intent. So no, I don't.
No they said "vim is intuitive, once X." Which is a different statement. It means "X => vim is intuitive," which can also be true when the antecedent (X) is false if going down the material implication route. Here X is "once you understand the characters."
I think what's happening is that even if we agree on definitions of intuitive, what I'm trying to add is the context around the "vim is intuitive" statement that it is scoped in. It is scoped by the "... once ..." qualifying fragment after it.
Also I'm not really saying what you should or shouldn't do. I'm saying try, because it could be fun; I want to see what happens when you take it there, sort of as a "hmm hey can we try this?" situation. It isn't as much a convincing as a "hey here's how I understand what he said--what do you think of that?" situation. More about going away with things to think about than "cool, I think I'm the person that won this argument." You're welcome to not try this, and I'll walk away, it's totally fine.
FWIW I agree that the unqualified "vim is intuitive" wouldn't be reasonable to say. I'm just trying to explore the nuance.
Actually, you do, when I said " vim is intuitive ( -ish?)", the -ish? is meant to convey the point is debatable and not an objective statement (user joemi and nikki93 understood my intent). I think I was right in saying that, seeing the number of replies to my comment.
Edit: funnily enough I added it (the -ish?) 30s after posting because I imagined this scenario, guess I could have been more clear.
If we're being so precise about everything, I'd like to point out that unless there is research that can objectively define and measure what intuitive is (we could still argue even after that) there isn't much of a point in debating the contents of my statement, especially when it acknowledges subjectivity.
Is it? I know what those characters mean, and I used to use vim, but I'm really not sure how they'd compose here. What does it mean to change and append at the same time?
In fact I just tested it and I'm still not clear what c2aw does. It seems to just do the same thing as c2w.
It does something similar to c2w if your cursor is at the beginning of a word. But if your cursor is already in the middle of a word c2aw may be faster / more intuitive than doing bc2w.
"a" can mean "append" but in this context (as the argument to a command) it means to change "a word". See :h aw for details.
It's better to think of it as "all word", as opposed to "iw" as "inner word".
It's easier to think about with "it" for "inner XML tag", apply stuff only between the opening and closing tags, of "at" for the whole thing, tags included.
So "dat" would delete the tag and its content, while "cit" would change the content of the tag.
That command might be intuitive to a vim user, but vim itself is anything but intuitive to someone who doesn't already know it. I'm disputing the intuitiveness of vim, which is what was claimed, not the intuitiveness of a key combination to a vim user.
Speaking of vim, just a reminder that @antirez made a terminal based text editor in pure C with no dependencies, not even ncurses, in under 1000 lines of code, complete with search feature, and customizable syntax highlighting for variable number of languages.
Lots of people have forked it and are actively making it their very own editor. Sure, none of them may ever take off and become a new emacs or vim competitor. Or maybe they will. Let's not discount innovation.
Plus it's amazing to me that to make a full fledged terminal editor, almost all you really need is the ability to read from stdin and write to stdout. Only a tiny little bit of glue C code is needed (for handling signals like SIGWINCH, or for setting or unsetting raw mode in the terminal), but almost the entire rest of it can be written in, say, Lua.
"The xi editor project is an attempt to build a high quality text editor, using modern software engineering techniques. It is initially built for Mac OS X, using Cocoa for the user interface, but other targets are planned."
At least until I started to seriously use it to level up my vi skills. Some of the links (say, for `a` or `g`) goes to the wrong places -- to the entry for `b`. When I stepped back and looked at how to navigate it, I realized the structure is disordered so I have no idea how to get to the info I'd like to see.
Well I started designing the site a few hours ago so - it would make sense it has bugs and is out of sorts at the moment. Better information architecture is coming down the pipe for sure.
One of my coworkers once shared the use of set relativenumber, which causes line numbers to be relative to your current position in the file. Great for movements.
> I think I can edit and navigate through text as fast as Vim users, using the native OS text editing hotkeys.
This is where I think you are wrong. An experienced vim user has so many faster ways to edit text than someone limited to what the OS provides. Here are some examples:
yt( - Copy characters up to the nearest (
ci{ - Replace text enclosed by curly braces
:g/\(['"]\).*\1/d - Use regex to delete every line containing a string literal
A vim master has thousands of permutations of commands at their disposal the specify exactly how they want to manipulate text in 5 or less keystrokes.
But navigation is just one great feature. Vim users can travel backwards in time (:earlier 10m), can have multiple clipboards with different content at the same time, easily record macros on the fly.
>faster ways to edit text than someone limited to what the OS provides
But other editors aren't limited to what the OS provides, they build on those basics to provide most of the same features, but in a way that's intuitive to modern users.
For example in Sublime:
>ci{ - Replace text enclosed by curly braces
Ctrl-Shift-M selects text inside brackets. Subsequent presses work outwards through layers of brackets.
>:g/\(['"]\).* \1/d - Use regex to delete every line containing a string literal
Ctrl-F Alt-R (['"]).* \1 Alt-Enter Ctrl-L Delete
>yt( - Copy characters up to the nearest (
Not available out of the box, but there are plugins for it. Although, in my experience of using vim, the mental effort of working out what character I needed for t/f tended to be far more disruptive than just using arrow keys/mouse.
Honestly that was my experience of vim in general. Whenever I had to do anything slightly non-trivial, it took a lot of mental effort to work out the exact command I needed. Whereas Sublime's multiple selections are more intuitive and flexible in unusual situations.
To use your regex example above, depending on the context, I'd probably just use Ctrl-D to step through instances of " checking whether each one is a string (which it probably is), skipping any that aren't, and then Ctrl-L Delete. (And repeat for ') If it's a short file, this is probably about as fast, it flows from muscle memory, and it means I'm actually checking through the changes I'm about to make. (And if it was a massive file, I'd use the regex. My point is just that Sublime offers a more ad-hoc way to do bulk edits where you're not exactly sure what you need to match on.)
>Honestly that was my experience of vim in general. Whenever I had to do anything slightly non-trivial, it took a lot of mental effort to work out the exact command I needed. Whereas Sublime's multiple selections are more intuitive and flexible in unusual situations.
Vim is humbling in a way. I have been using it for 5 years and while it destroyed my ability to use a non-vim textfield, which shows me what is already ingrained, there is always a faster way to do a task and always room to improve.
I like that. You come across a better way to do something and now you just remember to do that one thing wherever it applies until you do not have to think about it anymore.
> Although, in my experience of using vim, the mental effort of working out what character I needed for t/f tended to be far more disruptive than just using arrow keys/mouse.
I think you maybe didn't give it enough time. What really happens after a while is that you don't have to do any mental effort to do very complex things fast and efficiently. My experience is that after three months I had some sort of clicking in my head and everything made sense.
Said that, I wouldn't mind Ctrl-D on vim though, that's one of those sublime's features that I really like (and non consecutive multi line editing).
I gave it several years as my primary editor, and I did learn a lot of things. Then I switched to Sublime and became about as proficient in a matter of weeks. I could have put more effort into learning vim, but I didn't have to in Sublime.
Funny, Sublime was my gateway drug to Vim. It has "Vintage Mode" (which gives you vim keybindings) which I enabled just for macros since they are so powerful. After a month of going directly to insert mode I started accidentally picking up more and more random keys. Eventually I was so fast in normal mode it just didn't make sense not to use vim since everything else I use is in the terminal anyway.
Because vi is installed on almost every unix or linux system you will encounter. Many of the other editors require explicit installation, which may, or may not be possible depending on your bureaucracy and where the system is running in your infrastructure. If you know vi/vim you can work on files everywhere. Using the same editor everywhere is much less confusing than trying to learn several different editors and mentally flip back and forth between them.
Properly learning any editor is like learning an instrument. Once you're comfortable with one, you're going to be more comfortable with that one than the others.
Likewise, some editors are similar enough that you can chop and change quickly, others not so easily. Atom and sublime are like members of the guitar family, while vim is like a piano. They can all produce lovely text files in the hands of a skilled musician
Inertia for one, ubiquity for another. Vim (or at least vi) is available everywhere that I want to do any kind of text editing: An ARM SBC, my old WinXP laptop, my newer Win7+Linux machines, the old HP-UX at work, all the Linux VMs that I ssh into, etc. After almost 15 years of use, there are certain things that feel like a missing limb if they aren't present in another program.
Atom's not attractive to me. It's a ~100MB near-IDE written and extended in web-oriented languages that I'm only lukewarm on learning, and which can't be used remotely, or on all the computers that I'll touch in a given month.
Sublime looks nice, but not so far ahead of vim that I want to take the time to learn it and pay for a license. I suppose that it's worth a trial, but I haven't gotten around to it.
> Sublime looks nice, but not so far ahead of vim that I want to take the time to learn it and pay for a license. I suppose that it's worth a trial, but I haven't gotten around to it.
I use vim these days, but to be fair to Sublime, the license isn't really required. Every so often (maybe every 10 times you close a file?) it asks if you'd like to buy a license, but there's no functional restrictions on an unlicensed copy and no consequence for perpetually ignoring the pop-up.
I wouldn't worry about getting around to it too soon. Sublime is great, and it has a plugin to support normal/insert modes and most vim bindings, but I've found that anything I can do in Sublime I can do in vim, and I can't run Sublime on remote hosts. It's an editor, it's always going to be subjective preference.
> but to be fair to Sublime, the license isn't really required.
I understand that, and that's great for trying it out and deciding if I'd like to stick with it or not. Eventually, I'd buy the license, if I liked it well enough. Either I'd spend a bunch of time and learn some concrete reasons for why I didn't want to use Sublime, or I'd find a new best friend, pay $70, and change my workflow to doing more work locally rather than on the remote machines.
It may be worthwhile, and it may not be, but there's a guarantee that I'll be spending a bunch of time finding out. In the end, I was just trying to give a concrete answer for why I was using vim rather than something newer and trendier.
>I think I can edit and navigate through text as fast as Vim users, using the native OS text editing hotkeys.
I had to add 200 textboxes to a wpf form two weeks ago. Took me 60 seconds to generate the boilerplate with vim. If you can do it in under 5 minutes in notepad I'd be impressed, here's something similar to the data I was given: http://pastebin.com/Y7hyi2by
note: a) you can do this in excel with stringconcat, and b) the project could have been better designed to prevent the boilerplate but that was outside of my control
Major reason for me is that I rarely work on a local desktop. Most work happens on remote hosts. A local computer is an SSH term and a web browser. All the tools are remote.
Even in the rare case that I do something local, I prefer to keep using VIM becuase I know it so well and it is super lightweight.
I use both atom and sublime in vim mode. Also visual studio. I barely ever use actual vim for programming unless I'm throwing together a one off script on a a remote Linux terminal. When I say vim I usually mean something else with a vim extension.
Different strokes for different folks. For me, the first editor I ever used was vi and I just stuck with it. I've never used Atom or Sublime but from what I can tell they're nice editors too.
This is useful because it shows how to do many things in vim in easily consumable gifs. The letters are shown with dates because that's when the author posted each one. Probably not for everybody, I think it's kind of neat though!
Thanks for the explanation. Apparently not understanding this immediately counts as downvote-worthy. I was not trying to be snarky, it simply did not make sense to me. A better explanation on the page seems like it wouldn't be asking too much?
Vim may be daunting at first, but after you use it for some time, things just sink into your brain and fingers.
As some of you mentioned here, it is a professional tool, not easy to learn, requires patience and dedication, but I think in a long term, you will save much more time by doing so and mastering it, rather than sticking to some gui editors where you select with mouse.
Crazy to see this thing on the front page of hacker news.
First off - I JUST started putting the site together and didn't expect any attention yet. So apologies for the bugs and mismatched content. Pull requests welcome at github.com/mrmrs/vimgifs :)
I created vimgifs because I have found gifs to be an effective way to help people learn vim commands. And I really like helping people become more efficient at building out their ideas.
The long term vision is to have a comprehensive set of examples that can be searched in a myriad of ways i.e related commands, all motion commands,all commands available in insert mode, .etc. If it's in :help I want a gif of it!
I don't have an opinion on whether or not vim is 'intuitive' but I will say it is much easier to learn than people make it out to be. I'd say it is infinitely less complex than whatever language you are trying to write in.
It took me less than a week to become more proficient in vim than in textmate - and I knew most of the command and shortcuts in textmate.
To people who say they don't have time to learn vim, a counter:
If you are pressed for time so much that you are debating whether or not you have time to learn something... it sounds like vim is definitely for you!
Vim isn't just about key strokes, commands, shortcuts, and the like. The more I learn about vim's capabilities the more I fundamentally think differently about editing and manipulating text. It has branching history, native ability to step through compile errors for ANY language, and navigation methods that truly changed how I think about exploring/navigating a code system. It's also ubiquitous which is pretty rad. I can't remember the last time I touched a computer that didn't have my favorite editor already installed.
I would encourage people not to denounce something they have never possessed. If you are not proficient in vim - it is difficult to denounce how intuitive it is. It's tough to denounce its ways and how much time they might save you.
I have become quite proficient in atom, sublime, textmate, and a few other editors. Even with 'vim mode' enabled these editors do not come close to the power that lies within vim.
But rest assured you can write amazing software with any text editor. I've met a lot of people who are excellent at writing code that never use vim and don't like it much.
In short - I hope this project makes it more fun and less intimidating to learn vim. I was lucky to have some amazing teachers when I got going and would love to pay their efforts forward a little bit.
The performance could be increased (i.e less choppy) and filesizes could be decreased (i.e taking up less transfer of data for the same quality) by filming webm or similar rather than gif.
The only disadvantage visible is Internet Explorer users who don't have the plugin installed, in which case you could provide a gif fallback.
This is actually very good! My initial reaction was to roll my eyes at another Vim tutorial, but this suits my (low) attention span by giving me exactly what each letter does in a spoonfeed (read animated) way. Brilliant taxonomy (a-z) and brilliant bite-size aborption medium that doesn't require me to trawl through a tutorial. Bookmarked.
