Why, oh why, do those nutheads use vi? (2007)
viemu.com
viemu.com
Throughout the learning process one thing I observed was that, its just not enough to read about a cool article about Vim and leave it there. I would keep repeating the sequence of actions mentioned in the article atleast ten times every day and would find some usage for it during programming. I would intentionally force myself to use it, until at some point, the action I just learnt magically comes in as a replacement for a dumb action I was about to do. At that point I would know I've mastered it.
One of the most common things I use an IDE for is navigation (between files) and vim is not very good at it compared to IDEs, here's why:
* no tabs
* no project structure
* in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition
* in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
when I find myself actually writing code, it's usually a line or two in each of several files (because modern programming paradigms tell us we should split code as much as possible), or modifying some copy pasted snippet I found on google - so navigation is extremely important even when editing.
beyond that, there are simply some things that help writing code that a text editor cannot do:
* auto-complete(with annotation to tell you what the function variables are)
* debug inside your IDE
* run code-lint, auto-build on typing to detect errors, etc...
* auto refactor (I.E. extract method, move variable, extract class etc...)
* format all your files according to your pre-specified project guideline.
* sharing you IDE configuration with other contributors
* showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
There are probably projects out there where a full-featured text editor is a real game-changer and is worth the days/weeks it'll take to use it intuitively, but I never worked or know anyone who worked on such a project (even when I started projects from scratch);
Some are present by default.
> no tabs
It does have tabs, they're just called buffers instead(there is something called "tabs" too, but they're not what you expect tabs to be)
> sharing you IDE configuration with other contributors
Sharing your vim configuration is as simple as sharing your .vimrc
With buffers (unless I'm missing something) you need to type a command to list all your 'tabs' and another command to get to the tab in question. Project structure is similar - it's always visible, and you can always see what other files are close by.
I don't think that can be achieved with plugins, though I never knew there were plugins until now.
Do people who use vim regularly install plugins for it?
A nice configuration for Haskell which I often use to bootstrap new machines is haskell-vim-now(https://github.com/begriffs/haskell-vim-now). That includes almost all the features you mention.
This is somehow controversial to some[1] but it never bothered me.
As far as file navigation though, I just use crtlp[2]
map <C-J> <C-W>j<C-W>_
map <C-K> <C-W>k<C-W>_
set wmh=0
:sp <file>
[1] http://vim.wikia.com/wiki/Switch_between_Vim_window_splits_e...
I was already regularly comfortably using `Ctrl-^` to switch back and forth between the current and alternate buffers but I was also used to having different buffers open in different tabs and selecting them using either the `gt` family of commands or the `:tabfirst` family.
I like having the tab-bar provide visual cues for each of the buffers that I’m working with rather than having to type `:ls` to see the list of buffers (which can sometimes be very large as I often leave Vim running for a long time and if I do close, I usually restore it from a session).
Like you, I’ve yet to encounter any problems with this way of working. It’s possibly because I’ve never used any commands which utilise the quickfix buffer (`:make`, `:grep`, and `:helpgrep`) but maybe, there’s something else I’m missing?
There are many packages on GitHub that will install and configure Vim for you with a variety of useful plugins and keyboard shortcuts out of the box--so after the installation is complete, you'll have a fully fledged Vim IDE ready to use.
One of my favorites is Joe Nelson's setup [0]. It's specific to Haskell development, but even if that's not relevant to your use-case, it's a very sleek demonstration of what Vim can do as an IDE--and a good starting point for customizing your setup (i.e. a very clean .vimrc file for inspiration). I use it basically as-is for my default Vim config and as a full IDE. Check out the keyboard shortcuts for quickly switching buffers, Git integration, and the shortcuts for visualizing project structure & quickly navigating files.
Plugins have come a long way. For C# I use OmniSharp for Vim.
Check out http://editorconfig.org/
-> multiple vim plugins provide really confortable tabs.
* No project structure.
-> plugin. if you want that kind of tree next to your editor. (i.e. Nerdtree)
* in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition
-> tag search plugin. Haven't played with it much though.
* in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
-> I believe there are some plugins for but here i haven't seen anything good so far.
* auto-complete(with annotation to tell you what the function variables are)
-> you complete me. plugin.
* debug inside your IDE
-> good point. have to wait for Neovim for this - I believe. Installing current WIP version from neovim is on my todolist. ;)
* run code-lint, auto-build on typing to detect errors, etc...
-> syntastic.
* auto refactor (I.E. extract method, move variable, extract class etc...)
-> good point. don't know any good plugin.
* format all your files according to your pre-specified project guideline.
-> plugin.;)
* sharing you IDE configuration with other contributors
-> here truly most IDEs suck. For vim you find lots of shared vimconfig on github.
* showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
-> if you need to do in the editor... there is plugin for that. However, i found git command line is usually find. and for more serious committing I use GitX (L).
>> -> I believe there are some plugins for but here i haven't seen anything good so far.
Language dependent, Go has "Oracle" for example, for finding callers, etc.
> * debug inside your IDE
>> -> good point. have to wait for Neovim for this - I believe. Installing current WIP version from neovim is on my todolist. ;)
Clewn.
> * auto refactor (I.E. extract method, move variable, extract class etc...)
>> -> good point. don't know any good plugin.
Language specific, Go has multiple and lots of people write small bits of script to do this -- but it is a place IDEs are far ahead of Vim.
> * showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
>> -> if you need to do in the editor... there is plugin for that. However, i found git command line is usually find. and for more serious committing I use GitX (L).
Nerdtree & git-nerdtree.
I do agree that I'm infinitely more productive in an IDE than I ever would be with any plain text editor (e.g. autocomplete-hints, refactoring support, etc etc). After discovering the JetBrains suite of IDE's some years ago, I can't imagine using anything else for application development.
However, the point of vi/Vim is not so much the editor application itself... but rather its keybindings and modal editing approach in the abstract. Those concepts are decoupled from the actual editor, because every major IDE has plugins which make them available in its environment as well. The "IdeaVim" plugin for JetBrains IDE's is amazing, letting you mix-and-match between Vim commands and normal JetBrains shortcuts in a very intuitive way (or at least intuitive if you're familiar with Vim).
If you're happy with your current working environment, then rock on. But if you're fluent with vi/Vim (and it is a significant learning curve), then you can absolutely have the best of both worlds. To me, arguing about whether to use an IDE or an editor is pretty silly. But the question of whether or not to use modal editing and a suite of standard shortcut commands within an IDE is a much more interesting matter.
I don't think that matters so long as you're methodical in your approach to learning it. It's important to master the basics and then add new tools one at a time.
The amazing thing about vim is that each new command can be composed with your existing knowledge set, so just learning what, say, 's' does gives you a whole lot more power.
Also, while the discoverability might suck, the built in manual is just incredible.
-No project structure? Well, there is nerdtree. Or a separate terminal window open to the file system which is usually the way I do it.
-Autocomplete with annotation? Nice plugin for that.
-Debug? I'm running in separate terminal window anyway. I can debug there.
-Auto refactor? No thanks. I'd rather do that myself.
-Format according to guidlines? There is probably a plugin, but for the once or twice that happens third party tools work just fine. Don't need that in the editor.
-Sharing your configuration? Very easy. Just copy your .vim and .vimrc files over.
-Showing files in that aren't in version control? Remember my separate terminal window that's open? I don't want everything in the editor. But there is probably a plugin if you really need it.
____________
Here are the advantages: Cost, Ubiquity, works over SSH the same way. Takes two seconds to move my config files and I'm right back in the environment. Plus I know it and it is fast as heck. There probably some others I'm forgetting.
Honestly, it sounds like you haven't taken the time to get to know Vim. And that's ok... if you have something that work for you then no need. But lots of the things you claim are advantages of your setup really aren't.
One of my pains was that Vim-the-program was not ready to go, and that configuring or adding plugins to Vim was a real nuisance, and I think due to terminal limitations, Vim-the-program could never have some of the features other programs had.
> * no tabs
There actually are tabs, but they probably don't work the way you expect, they are closer to viewports or workspaces, but they are there. You can also use assorted plugins to improve tabs and/or emulate them.
> * no project structure
Not sure I understand this way -- no enforced structure? Neither to IDEs, no tree viewer -- there are bunches of tree based file viewers.
> * in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition
This is supported by the tags system in Vim, which depends on ctags. :tselect, C-], lots more -- this exists out of the box.
> * in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...
This obviously very specific to some language you have in your head, as many of those things don't make sense in some languages. That said, this is supported in various languages by various plugins (In Go, Oracle for example).
> when I find myself actually writing code, it's usually a line or two in each of several files (because modern programming paradigms tell us we should split code as much as possible), or modifying some copy pasted snippet I found on google - so navigation is extremely important even when editing.
Agreed, which is why Vim has so many ways from jump-to-def to jump-to-file to various smart plugins for rails and C and <X>.
> * auto-complete(with annotation to tell you what the function variables are)
Gobs of plugins do this for Vim -- normally language specific and they tend to work rather great.
> * debug inside your IDE
See Clewn, full gdb support integrated with vim.
> * run code-lint, auto-build on typing to detect errors, etc...
Vim has all of that, syntastic will show errors in the left bar as you type, setting things to autorun is trivial, all major languages already have this.
> * auto refactor (I.E. extract method, move variable, extract class etc...)
Language specific (as is your IDE's features, because to do requires understand the language), but this exists in limited form for Go and C++ -- and I am sure others. The level isn't up to major IDEs. That said, many of these things are easily scriptable in vim.
> * format all your files according to your pre-specified project guideline.
Tons of vim support for this, even supporting standard 3rd party like EditorConfig.
> * sharing you IDE configuration with other contributors
I think you will find far more vimrc files shared in the wild than any IDE.
> * showing when files are/aren't in version control and integrating version control so that you view history in your IDE.
Fugitive has great time travel features for flipping through versions of files and seeing differences. Use git-nerdtree to add git status to nerdtree.
Zealots trying to convert unbelievers is plain obnoxious. Your choice of editor isn't a religion so use what you use and I'll use what I use and you don't have to worry that what I'm using isn't what you are.
You are missing the very point of a shell. Text gives you power, composability and flexibility that you simply cannot achieve with a GUI. Automation becomes extremely easy because of this.
Editing text without having to move your hands back and forth between keyboard and mouse makes it so much faster and lets you concentrate on your actual work instead of breaking your concentration.
Vim has its own vocabulary, and the essence of vim commands is composability. You imbibe this vocabulary over time and editing text becomes effortless like stringing together words to form sentences and sentences to form paragraphs.
The shell is so successful precisely because it uses text as a common representation for all data. It simply wouldn't work with a mouse. Many people have tried this and failed.
Computers are good at manipulating text and humans are good at understanding text. The abstract geometry that you have to use to describe mouse movements is neither intuitive, nor is it easy to process.
Can you think of any big things that you lose though?
> Editing text without having to move your hands back and forth between keyboard and mouse makes it so much faster and lets you concentrate on your actual work...
I could probably get between floors in my house an order of magnitude faster if I replaced the stair cases with slides and a trampolines. Somehow, that does not seem practical though.
> The shell is so successful precisely because it uses text as a common representation for all data.
Successful in what way? As successful as GUIs?
> Computers are good at manipulating text and humans are good at understanding text.
Humans are good at understanding patterns and symbols and they're not good at memorizing text commands. That's why everybody can use GUIs but few can use a shell.
They each have pros and cons. GUIs are generally more discoverable. Terminals are /way/ more flexible, faster, and customizable if that's your job and you take the time to learn them.
> Can you think of any big things that you lose though? Definitely. Customizing behaviors. I work with image sequences a lot. "ls" is used to list files in a directory "lss" is a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui, you need to re-write your whole file-browser or have one with some plugin system that support this (I don't know of any).
> I could probably get between floors in my house an order of magnitude faster if I replaced the stair cases with slides and a trampolines. Somehow, that does not seem practical though. That's a terrible analogy and a half-truth on both sides. Jumping to the mouse does slow things down, but I use GUI file browsers without a mouse just fine. The only thing I can't do out of the box is resize and move windows around--navigating through directories is fine.
> Humans are good at understanding patterns and symbols and they're not good at memorizing text commands. That's why everybody can use GUIs but few can use a shell. I think the difference is that guis offer more spacial queues and persistent information than terminals do. Someone who has never used a computer would be equally confused at how a mouse or scrolling worked. Humans are not terrible as memorizing text commands, there's just no need to use them everyday and a gui is usually good enough. Fewer people can drive a stick-shift or parallel park now that it's generally unnecessary. It's not that it was difficult. I imagine in a few generations after automation takes off driving a car at all will be difficult for most people.
You didn't say how you arrived at the conclusion that shells are "so successful". How are you measuring that?
> ...a command we wrote to group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial. These are technically possible with a gui...
Those things are eminently possible with a GUI without writing your own file browser since most major file browsers offer a range of extensibility options. Also, GUI automation is a thing and it works well. Just last month I wrote a simple script to automate image extraction from a program that didn't provide any API for it. As a matter of fact, I didn't even have to write most of the script because the computer aided me by recording my mouse clicks.
> Jumping to the mouse does slow things down.
Looking up commands and configuration protocols slows things down way more though.
> Someone who has never used a computer would be equally confused at how a mouse or scrolling worked.
Equally as confused as they'd be when presented with nothing more than a blinking cursor? I don't think so... Once you move the mouse and see the pointer move, it's pretty obvious how movement works. Sixty seconds is enough time to accurately convey complete operating instructions for a mouse. Teaching someone how to use a shell would take much more time I imagine.
Anyway, I use a shell when it suits me and a GUI when that suits me, but most importantly, I am not a bigot or an elitist about it. I don't think that there is one true way to do things.
It hasn't been explicitly said, but all of these arguments are implicitly about file browsing and file management. I can't imagine anyone exclusively using commandline tools for things like audio editing, browsing the web, etc.
I'm genuinely interested, how would you write something like that for a file browser on any platform?
A GUI program can do everything that a command line app can do and more, but unless we discuss exact requirements I can't answer the question very precisely. In terms of input and output I think there are generally more options with a GUI though.
Funny story on this topic - last night I was playing around with Fedora 21 + Gnome 3 and when I used git (in a terminal), whenever it needed a username or password it would pop up a GUI with a single text input. It's called askpass and I still haven't found out what exactly necessitates such a workflow, but I thought it was pretty hilarious.
> ...on any platform.
Command line programs don't work on every platform. Far from it. They don't even work on every Linux distro and especially not with normal usage on variants such as Android. So that's a bit of an unfair requirement to add just for GUI apps, don't you think?
I think we're in agreement that they both have pros and cons. It certainly can be easier to write a command line application that works on all platforms. I wasn't arguing against that - I was arguing with the guy on this thread who seemed to think that command lines are the single best way to interface with the computer. The guy who responded to almost every dissenting point of view...(not you). I didn't realize that it was not you at first, but my first response was to that person.
There are a lot of things I like with a terminal; history, tab completion, man pages (all OS help pages are generally useless. The only aspect I've ever liked is OSX's searchable help menu that will hightlight menu options). On the gui end you can't beat the discoverability, window management, but a big win is an undo stack. I feel like touchscreens are a step back in discoverability (but they have their own merits).
I think terminal people really latch on to the composibility of Unix apps that are provided via pipes. I've seen people try to come up with a gui equivalent (copy/paste is the closest), each gui feels like a walled garden (almost as bad as iOS apps). Something like AppleScript or D-Bus tries to address this, but I feel like if you're writing a script its basically a less-interactive shell. Automator seems like a decent take on this, but not too many apps expose an api for that and I've struggled trying to get it do what I wanted.
Just one question regarding the program you described - you're talking about the "lss" command you wrote, correct? You said that it exists in order to "group image sequences together. This makes finding missing images in a sequence, knowing the range, and dealing with 1000's of files in a folder trivial".
I don't know how you're grouping image sequences together, but I can't imagine why a GUI wouldn't be able to represent image groups as well as or better than a terminal program. Could you tell me? Alternatively, is your program open source? I'd love to check it out.
Here's a custom file open menu from one of those apps that wrote their own implementation (you can expand down to see the individual files): http://www.tweaksoftware.com/static/documentation/rv/current...
Here's a Python library with generic grouping logic: https://github.com/4degrees/clique
The hooks are there to do it though, at least in Windows Explorer and Gnome/Nautilus. Something very similar built into Windows with html file/folder groups and zip files. There are tons of third-party Windows Explorer extensions that change the way files are displayed. You can definitely create virtual nodes and hide nodes that you don't want to show (even in native open/save dialogs).
While I have no doubt that it would be possible on OS X, I suspect that easy-to-use hooks are not available for Finder like they are in Windows Explorer. You can write a QuickLook extension for Finder though.
(Some file browser extensions are easier to write than others. The image sequence in particular would definitely be easier to implement
Plan 9's ACME or it's descendant probably.
The fact that you have not made a single counterargument to any of my points betrays a lot.
Now you can feel fulfillment when you log into your graphical OS and instantly open gazillion terminal windows to bypass all the progress that has been made in last 20+ years... because computers are better processing text then graphics.
I grant you one thing: when you sit in your cafe pretending to work on something infinitely more important then everyone else, girls/boys will be impressed by the complexity of your screen...
This argument ("Oh I use <insert console based editor> because I can use it on my laptop or via SSH on the server") is fucking stupid.
If you can learn how to use fucking vim or emacs, you can learn how to use configuration management - either through a "full blown" tool like puppet/chef/ansible/etc or through config packages (if you're on debian) or even through plain old shell scripts.
Except when it's not really your call. And you have to poke around files so far down behind God's back through a shared desktop Enterprise VPN IE-only plugin-fest, that you don't even know which way is 127.0.0.1, then you're happy that you have vim on Dear Client's pointlessly supported RHEL boxes by default.
And othertimes, when you want to debug something that only happens on a live/production server.
Editing files on the server live is - in itself - not right or wrong. Doing it as a regular workflow is what's bad.
Oh, and if you're editing system config files for systems administration tasks? That's on the server. As GP said, if you come from a sysadmin background, you're used to using a keyboard-only editor. And Vim sure beats ed.
If you're doing it infrequently this is even more of a reason to use a reproducible system, otherwise recreating the environment when the inevitable happens is even harder (you don't even have the benefit of repeated steps to aid you in the process)
I know some of the existing tools are a massive overhead for small operations - that doesn't make the goal in general any less worthy.
I agree calling it better than any other editor is erroneous. There is emacs too, but that's about it.
You need type completion because your brain shouldn't worry about whether the method is called `updateBufferFromStorage` or `updateBufferStorage`, it should be focused on writing the best possible code.
Emacs is a good Elisp environment. Evil-mode turns it into a good editor :P
I agree with the statement "use the right tool for the job", but people shouldn't diabolize something without knowing why others swear by it. FYI, in most cases we use Vi(m) because it's the fastest text editor available, not an IDE.
Granted if what you are doing is actually editing text then it makes sense to use Vim or Emacs, but I find that I relatively rarely do that.
The author believes that <Technology X> is superior to the alternatives, and wrote a blog post complaining about people who pressure its users to switch away. That's not exactly Jehovah's Witness knocking on your front door to thrust a magazine in your hand. In fact, the conclusion section starts with, "Do whatever you want. Don't learn it if you feel it's too much effort just for nothing.". The gist of this piece doesn't seem to be "converting" anyone. Ironically, it seems to have been inspired by receiving such pressure from others.
Half of Hacker News consists of discussing why all users of last week's fad should abandon it and jump onto this week's fad (e.g. "MySql -> Postgres -> MongoDB -> back to Postgres"... "Ruby -> Scala -> Node -> Go -> Rust -> Julia", etc). If you're looking for obnoxious zealotry, there are plenty of better threads in which to look.
I'd argue with that.
It's like getting your head stuffed into a toilet bowl at a boys' boarding school. Afterwards, you feel like part of the gang.
These two things were worth the other inconveniences of ed, IMO, until I discovered automatic tiling window managers...
For vim itself: I have seen friends trying to learn it. I have seen PhDs and postdocs use it. I have seen coworkers use it. The only people who I could see were editing text as fast as friends/PhDs/coworkers using Sublime were my tech leads. The smartest most proficient and effective programmers I have ever met. Everyone else was slower, at times wrestled with the editor (by this I mean that they executed commands and had to redo them because they didn't do what they wanted). I guess the conclusion is that people can learn to use vim as proficiently as Sublime, but most will fail or it will take them years (and I mean 5 or 10 years).
Actually, two of my tech leads, when I showed them some trick in Sublime were like: I should look into this. Maybe I'll just boldly argue that vim is inferior after all :).
Then people started talking about Sublime 3, Atom, and all that editor hotness. I wanted something stable, something I could learn once and be comfortable with it being around for a long time. I had tried Emacs years ago and found it unpleasant, to say the least.
I looked into Vim. It became very addictive but it does take a bit of time to learn. I love the action followed by motion idea. I found the built in tutorial decent as well as Painless Vim to be a decent starting point: https://leanpub.com/painless_vim
About a year into my Vim conversion, I get around decently and love doing the editing stuff. But I do feel that I need to go over tricks and tips again.
So I'm often quite delighted at learning new things with it, even still! And to be frank, I think this is one of the things I most like about vim - even though I've been using it for years, there are still undiscovered treats yet to be revealed to me, over and over. When I discovered cscope integration, some 10 years ago, it was like getting an OS upgrade .. in my editor! :)
However, often we know that we don't know how to properly design something and we start implementing too early. The end result is sth like: 50% coding, 30% testing and the rest is squeezed into testing, deployment and requirements analysis.
Funilly i realized that very early at university, where i had to perform a code exercice while on holidays, but forgot to take my computer with my me. I did it on paper, then typed it when coming back home, and got the best grade.
I can imagine it to be a little like holding a speech with a stutter. Sure, most of your time is spent on prep. That doesn't make the pauses less annoying when you're actually talking.
But I don't stutter, so maybe that's ridiculous.
Why are you spending such a vast amount of time on something so simple as data structures?
Seriously. It's pretty much a solved problem these days. You should have read enough of other peoples code to see the common patterns, especially in your industry.
I'm serious that if you spend a lot more time on white boards and paper than programming in this day and age, there's something wrong.
I suppose you're just writing boilerplate code, assembling pre coded components within the boundaries of a framework... That's the kind of boring job i usually try to let interns or beginners do, mostly because it's not economically interesting for customers to have that kind of job performed by senior devs/architect ( it does take more time than brain).
We're way past the decades where you had to sit around "thinking" for ages to come up with a data structure. You still loading the program up on cards or something? You saying it is as preposterous as the guy I met a couple of years back who offered to come and design SQL DBs for me. It's just not done any more. That's not how we work any more, that time has past.
In today's world you can prototype up the basics of any complex system in an hour or two and throw it away if it doesn't work. Tests are cheap, it's easy to mock, there's no compilation to worry about. And if you can't look at a problem and immediately see the effective ways you've solved similar problems before, well, you're not as senior dev/architect as you think you are.
You simply sound dated to me.
Now of course you don't need this method for trivial things, but i hope that's not what you spend most of your time working on.
Note: i didn't downvote you.
vi can be a huge speedup doing text manipulation. Programming is not just manipulating test, but manipulating code. An IDE helps me with syntax, completion, extracting/inlining, modifying signatures, refactoring, etc.
A corollary is: if you're making a tool, make sure it's leaps better than the simplest alternative. I have a friend who gauges lasagna at a restaurant against Stouffer's frozen lasagna. Because Stouffer's is delicious and if I'm going to a restaurant and paying a lot, it has to at least be better than something I can easily heat up at home!
In particular, the author emphasises that you leave Insert mode as soon as you've stopped typing. When I first started using Vim, I used to spend too much time in Insert mode while moving around using the arrow keys.
What I learned from the article: If you're not positioned on a parenthesis, the `%` command will “scan character by character to the right, until the first one is found, and then moving to the character matching that one”. Until now, I’d always been using one of the `f`, `;`, `T` family of commands to move to a parenthesis or equivalent character. This will be a real time saver.
I've never grasped vim. It was too slow at the time and the extended command set consumed all the free keys I use to have available to do my own macros (eg: 'q' 'g').
I reckon vim grew to be much more than an editor, it is now an editing plataform, capable of so many things, and contains lots of shortcuts / builtins for common text-editing situations.
The article above contains many vim-only commands. For example 'di>' ("delete inner angle-block") doesn't exist on standard vi, neither the '>aB' ("indent a Block").
I have hopes that neovim will sort some of that out -- it makes a certain amount of sense that vim is slow because of some baggage it carries, but I'll admit they aren't very high hopes: I've been using emacs recently.
How funny is that? That I use emacs because vim is too slow!
Indeed, if you're writing lots of code with hardly any newlines (like k lang), you will probably have performance issues with vim.
> It also has terrible defaults
filetype indent off
filetype plugin off
filetype plugin indent off
I also really wanted vi bindings for navigation in team chat (isn't it the most obvious thing ever?), so that's how we made it work in Kato (https://kato.im/articles/en/power-users/keyboard-control)
"No, they are not dinosaurs who don't want to catch up with the times - the community of vi users just keeps growing: myself, I only got started 2 years ago"
Using batch to write FORTRAN, the editor was a card punch. On the Deck-writers (teletype) and VT100 terminals, I used to write Pascal, Ed was the only choice. Early Linux use forced your hand, Ed (again? NO) or Vi. This is because Emacs is a 30Mb download and where space was a premium. [0] Try using anything but Vi or Ed with Busybox. [1]
So I stick to Vi(m). I can use any cli editor but with much time and effort in Vi usage why change? I can but why?
[0] esr, "A Tale of Five Editors", http://catb.org/~esr/writings/taoup/html/ch13s02.html
[1] grep "emacs" here ~ http://www.busybox.net/downloads/BusyBox.html
Wouldn't it be more useful to have commands for going to expressions, blocks, scopes and other code level structures?
I see vim people suggesting always leaving blank lines around functions, so you may use paragraph shortcuts to move them around. Why?
But I use sublime or some other graphical editor when I am on my own computer.
Also it's gimped without addons which you very much miss when using someone else's machine.
And if they happened to not have compiled with clipboard support, you're in a world of hurt.
I was fortunate to learn vi by rote, in a series of lectures where there was no computer in the room. Yep, copying the likes of ':wq' from the hand-written blackboard to A4 paper, along with all of the other 'handy' commands, some of which such as 'yank' I do not use to this day. This was a whole different way of learning with the notes referred to rather than things getting 'Googled'. Was this a better way to learn vi?
I don't meet so many 'vi' experts these days, if anything I feel embarrassed to be using 'vi' and associated command line tools like 'grep' when everyone else has some auto-completing high-speed IDE instead. I have to 'psr-fix' my code to make it sufficiently elegant. The problem for me is that I can do most things in 'vi' without having to hunt around for menus etc. Therefore, moving to the new is hard for me. In some ways I am like a secretary knowing 'Wordperfect' 25 years ago and unable to adapt to 'MS Word 2.0c' due to the same UI problem and convenience of known tools (Wordperfect, Vim).
I also do not feel that 'vi' works well in a team, people with Mac-gui-loveliness computers just can't edit things on your computer on an ad-hoc basis, some visual editor has to be found just for them.
If you are a vim person then these funny new-fangled 'gui' editors are really dangerous. It is far to easy for the document to end up with mystery 'j' characters added to the first line, ':wq!' added somewhere at the end, maybe with some randon 'ijk's' in the middle. If you are a vim person then every editor should have an 'insert' and 'normal' mode, not just 'insert'. The rest of the world doesn't see that though.
With people that do use 'vim' I have noticed that everyone does things differently. Some people will regularly use a feature that you never use, to make you wonder why you don't know that trick. Life without the correct, personalised '.vimrc' file is also quite hard, however, I have found some of these that others use to be overly 'souped up', for instance the search, I really do not like the search-as-you-type option, old-school is better, where you need to press enter.
So everyone finds their own dialect of 'vim'. Like car drivers, everyone thinks they are a good 'vim driver' apart from those that haven't learnt to drive. And they shouldn't. Amazing that vim is, it is a relic of former times, there are better tools with better 'UX paradigms'. In my field none of the 'programming gods' use 'vim' as they can't get to their productivity levels with it, so they use modern IDE's for their work, retaining enough 'vim' for any server side config file editing.
Turns that many of these (including IDEs like Visual Studio or Eclipse) have add-ons or built-in modes which emulate a useful subset of vim's behaviour.
> Life without the correct, personalised '.vimrc' file is also quite hard
Is it? For server-side work, I have a "light" vimrc of a few lines with sensible settings (status bar, nohidden, expandtab, this kind of thing). It is trivial to recreate if I don't have a copy. I have a longer vimrc and quite a few add-ons, but it's for more specialized work, not really anything I need for editing a remote configuration file.
> In my field none of the 'programming gods' use 'vim' as they can't get to their productivity levels with it, so they use modern IDE's for their work, retaining enough 'vim' for any server side config file editing.
In a large part, it depends on the language you use. Nobody sensible would work on a mid-size Java project in vim.