I've only skimmed this but there seems to be a focus on customizing and plugins from the get go. I think it's worth getting to know Vim "as is" before doing such things. Indeed there certainly some things that aren't the most useful or obvious but it's good to understand their original intent.
Not to crap on the author of this but I'd recommend Drew Neil's Practical Vim over this (and pretty much every other Vim book).
I kind of agree but vim's defaults are awful. Tim Pope has put together a good set of non-opinionated defaults which don't change key bindings or customize it otherwise [0]. I have a very similar vanilla setup with no plugins apart from syntax highlighting for some languages not included by default.
I agree. Personally, I prefer getting used to the defaults than going through the pain of customization. I tried it, but it meant additional syncing between my machines, fighting with plugins, and it's not always possible to customize vi mode in some environments (like Eclipse or Sublime).
Overall, I think vim is great for simple and fast editing, but as soon as I need to work on a multiple files projects, I switch to something else, possibly using vi mode if there's one (and even there, I wonder if I shouldn't embrace mac os shortcuts once for all).
Copy over one file (.vimrc) and you're done. If you use plugins, then copy them over with git or whatever. And my setup is very conservative so it's mild annoyance at worst.
The defaults are just bad, I recommend using vim-sensible or doing your own lean and mean vim config.
hjkl (not jkl;) are a) ergonomically bad because they are one key off of home row position and b) completely useless for anyone who types with a different keyboard such as Dvorak, and presumably some foreign language ones.
also, HJKL actually IS the arrow keys... but it's the arrow keys from an ancient computer that no longer exists. People get all uppity about it being the "right" way but there's no logical argument that supports hjkl on a modern computer OTHER than the fact that it's the default.
I disagree with this. The j key is the most used out of hjkl, and it's under your right index finger. I do most horizontal movement with left hand (primarily w and b) anyway.
Actually there was a time when everbody knew the ASCII table and hjkl were the control codes for backspace, linefeed, vertical tab and formfeed which map pretty closely to the 4 arrow directions. The first two are keyboard oriented codes, the next two are more line-printer codes but the early teletype terminals were just a printer with a keyboard so it made perfct sense.
In the vi world, these keys didn't really mean anything. They were just easy mnemonic associations to memorize because there was a system of relatedness to all of it.
In default vim, i inserts to the left of the cursor. In ijkl, you simply map h to insert left of the cursor. It's even on the left of your new arrow keys so the mental map works better too!
I'm a huge ijkl fan, because I learned wasd long before I learned vim.
out of interest - as hjkl are one offset from the default jkl; home row position, do you opt to use the index for both h and j or shift your hand one key over to the left?
I notice from observing other people type that there is an aversion to moving hand position, whereas the idea of moving hand position is not unfathomable to me, perhaps as I have played piano and violin. For example, I generally use middle finger to hit esc to exit escape mode. This may seem counter-intuitive and could well be thanks to the dimensions of my hand, but I am able to reach esc with middle finger without moving the wrist. That means I can hit esc and find the home row while still touch typing. Similarly, displacing my entire hand for hjkl isn't that uncomfortable and is certainly more comfortable than trying to use both h and j for h and j.
I use Ctrl+[ instead of Esc, since I find that far faster and requiring less hand movement.
I notice from observing other people type that there is an aversion to moving hand position, whereas the idea of moving hand position is not unfathomable to me, perhaps as I have played piano and violin.
I'm not averse to moving hand position, and I don't use the strict one-finger-per-key rules either, but I do try to minimise hand movement overall since it means faster typing.
I find that people who consider remapping capslock to anything else are people who don't know how to touch type. If you are in that camp I would strongly recommend spending the time to retrain yourself to learn how to touch type with home row position. You'll find that the capslock becomes a much more valuable key. You'll also find that your wrists are happier. It's an annoying time investment,but it's a valuable one. I combined it with switching to Dvorak... which really hampered my typing speed for a couple weeks but also helped improve my wrist happiness.
My keyboard has one minuscule control key so I prefer to map control to caps lock, but I map 'jj' to escape in insert mode, which makes it super quick to switch modes.
I must be weird or something but I've gone back and forth between vim and emacs for years before finally settling on just vi (Keith Bostic's nvi, to be exact).
I've spent countless hours reading about and installing plugins on both of those big editors instead of just getting work done. Now that I just use vi, I realize how little of that stuff I need and how much I can get done with just macros and ! (the shell out command).
I've encountered several quite painful behaviors of traditional vi that vim fixes. For instance, with traditional vi, if you start out changing a region, you can't move or change text outside that region without exiting insert mode.
I actually like that feature. I try to stay out of insert mode as much as possible. This feature lets me mash C-w or even C-u without worrying about changing text outside the original scope of my edit. I use the c command to change text inside of an html tag (for example) and I like that this protects me from damaging the tag itself.
That's the way vi is supposed to work, since it is based on the paradigm of a modal editor.
I learned vi in vi on UNIX, so the modal way stuck and I can glide and float between vi on UNIX and vim on Linux without getting busted on trying to move with cursor keys. I see Windows/Linux users get busted on that a lot, because they didn't install UNIX at home and learned on that first. It's frustrating to watch them get busted by that in person, over and over again.
vim isn't the "on a server" editor for me, it's the "everything" editor. I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes.
(As an aside, for me the main value of syntax highlighting isn't the normal case, but rather the case where the syntax highlighting emphasizes a problem, such as an unterminated string or other typo.)
I like that it works the same way everywhere, but I primarily use it to edit files that do have recognized filetypes.
UNIX doesn't care about filetypes, since the paradigm is working with binary streams of data, and it's implemented in a way that users don't need or have to care either. File types are a concept from MS-DOS, popularized by Windows, and a major hindrance to a UNIX user's workflow.
Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script. And if I edit a file named "*.c", I'd like vim to provide syntax highlighting for C. That highlighting makes it far easier to spot typos.
UNIX didn't support a wide variety of things people expect and find more user-friendly on modern systems. At an OS level, the OS should absolutely treat everything as a bag of bytes; that doesn't mean every tool built upon it should.
Vim recognizes and cares about file types. If I edit a file with "#!/bin/sh" at the top, I'd like vim to provide syntax highlighting for a shell script.
Well I wouldn't, and the entire purpose of using UNIX or a UNIX-like operating system is that such things are a strictly intimate, individual, private affair.
The example you cite serves extremely well for the purpose of illustration, of how there are no file types in UNIX, and how neither the operating system, nor the user should care.
Why should the user care? For example, I don't want files in the bin/ directory to have .pl, .py, .sh, .exe, or .com extension! Does it have an x bit set, thereby being executable? It does? OK, run it, and I couldn't and shouldn't care less what it's written in, because that's the main reason why I use UNIX to begin with!
Same for coloring: I hate colors in vim(1); hate, hate, hate, and do not need or want coloring in order to spot syntax errors, as I have the compiler, the linker, and the shell's set -x for that ("do one thing, and do it well")! Why should I suffer if you like colors and syntax highlighting? That should, and on UNIX is, an entirely private affair. GNU/Linux broke that, because users came from Windows, expecting GNU/Linux to behave like Windows but with a shell which isn't braindead. If I wanted to use Windows, I would be using it. If I wanted to use an integrated development environment again, I would be using it instead of vi(1) to write code. vi and vim, by the way, are text editors, dedicated to doing one thing and doing it well, and to expect them to behave like an integrated development environment leads to sadness, pain, misery and confusion.
UNIX does not have, recognize, or care about file types; consequently, it is up to the application to implement mechanism for dealing with the stream of bytes which the operating system does provide. In your case, that application is vim(1), and the file type recognition is proprietary to it. It has nothing whatsoever to do with the operating system.
On AmigaOS, where vim(1) comes from, no such vimrc file is provided; consequently, vim(1) doesn't treat .h, .c, or AmigaDOS shell scripts in any special way. This is because AmigaOS does implement data types, which are generic file type drivers, and still neither the operating system, nor the user care about file type extensions!
On Solaris and illumos-based operating systems, for example, vim packages do not deliver such customizations as they do on GNU/Linux, and consequently, there is no highlighting or any other special handling of .h, .c, or any other file type. (z/OS on the mainframe is even better, there are no files or byte streams to speak of, only records, and they are all binary.)
It's just a very bad Microsoft screw-up from MS-DOS days which has conditioned an entire generation of hapless Windows-now-turned-GNU/Linux users to still think of files in terms of file types and integrated development environments, because MS-DOS and Windows came without dedicated tools out of the box, so people started writing one-program-does-it-all, monolithic applications. What would you do on z/OS, where there are no files, just records?
This is one of the core concepts of UNIX: policy over mechanism; UNIX specifies policy (stream of bytes); mechanism is left up to the implementer.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
You are likely to find .c and .h files, but for UNIX, that is also just another stream of bytes - it cares not that the stream of bytes happens to be in the ASCII, 7-bit range.
UNIX doesn't treat them in any special way. There is no such thing as file types on UNIX. That concept does not exist, nor is it needed on UNIX.
If one wants to classify a file at-all-costs, we have the file(1) command on UNIX, and that command consults /etc/magic (see magic(4)); if magic(4) does not contain the required byte stream excerpt, the output of the file(1) command will be an untrustworthy approximation at best. And still, the file(1) command is strictly for humans who feel the need to classify-at-all-costs, not for the operating system.
You can, but Windows will ask you which program to open it with every time, because it uses extensions to classify file types, and since the file doesn't have an extension, Windows is incapable of handling it automatically. The fact that it has to handle files at all is a lost cause, conceptually. One bad decision begets another in Windows, which is all well and good, just not when that nonsense starts permeating into UNIX, where it is neither wanted nor needed - it's an artificial, unnecessary thing there.
No they do not, what in the world gave you that impression?
UNIX desktop environments indirectly rely on /etc/magic to decide what to do with files. If you are using a desktop which actually maintains a database of file extensions and you also think that that is okay and that that is how things should work, you are on a wrong operating system, and Microsoft Windows or even MS-DOS is a much better fit for how you expect the OS to work.
Even so, a desktop environment on UNIX is just yet another application, sometimes it is just a single process. The operating system empathically does not provide any kind of file type recognition or handling for such a desktop environment application, and any such file type recognition and handling is proprietary to that application.
Since the core UNIX paradigm is one of everything is a file, and all files are nothing but a stream of bytes, the OS has no concept about the contents .h, .c, not shell scripts, let alone .wav, .au, or .mp3 files, for instance. The UNIX operating systems only deliver streams of bytes at the request of applications via the open(2) and read(2) system calls. That's policy. The mechanism of what applications (consumers) of that or those byte streams do with the stream is left up to the applications which consume the streams:
A Unix File Is Just a Big Bag of Bytes
A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no capability to store information about the file type or a pointer to an associated application program outside the file's actual data.
That is KDE specific, and has nothing whatsoever to do with the OS.
How does your KDE handle file types when you are logged into a headless server, without any kind of graphics hardware, and your console is a serial port? How does the UNIX kernel handle file types when you're on a headless server with no graphics hardware, and your output is stdout on a teletype terminal or a nullmodem cable on a serial port?
I guess you missed the point of everything I've written so far. Did you read the links I provided?
Upvoted! Same here; I hate it when syntax highlighting makes it difficult for me to see the code, when I'm on a server and am just trying to get some work done. I cannot comprehend why I would want to see code in all those colors, with horrible contrasts, hard to read? Why? I know the syntax of the code, don't need or want anyone shoving what they think I need or want down my proverbial throat!
Vim used to have very very conservative defaults, but it was fixed in Vim 8. Some very useful features like persistent undo are still not enabled by default.
Bear in mind that that feature is disabled for good reason, it has some serious security implications (e.g., your visited file history is potentially leaked, as well as sensitive text ending up in your .vim folder).
It doesn't automatically `:set et sw=4 ts=4` in Python. When editing on a server, this can be downright annoying at best and deadly at worse, if you accidentally get a tab in the resulting out.
(We've started deploying something like vim-sensible, though I didn't know about vim-sensible, so I might start deploying that.)
For instance one of the first things to do is set incsearch for incrimental search as you type out search terms, the way every modern web browser, IDE, and emacs work. Also I think using 'set hidden' should be a good default for pretty much everyone.
Developers spend 99.9% of their time working in their local environment, so this isn't very important for them. If you're a sysadmin, then it makes sense, but then you're probably already proficient enough with vim or some other editor that works on your server.
I don't think it's very hard to switch to stock vim, when the keybindings remain the same. Most of the customisations commonly used are either cosmetic (syntax highlighting, brace matching, search-as-you-type, etc) or don't require much adjustment (delete through all text, etc).
I wonder whether that is because of vim compiled defaults or the way people who package vim think things should be, or both?
I get so angry every time I log into my newly created Linux account and fire up vi, wanting to get some work done, only to find out that it's been aliased to vim, and there is that horrid syntax highlighting turned on. Unbelievably irritating, and frustrating to no end.
Ironically, on AmigaOS where vim comes from, there are no customizations and no syntax highlighting - vim just works there as one would expect vi to work on UNIX.
To perhaps go against the grain a little here, I appreciate a focus on customisation from the start.
I am beginning to use Vim more, mostly because I was introduced to the keybindings with Vim emulation from other apps, and I appreciate how it works. I had previously attempted to learn Vim through the normal ways, but it just was impossible; by default, Vim for me is barely readable and none of the included colour schemes ever made it any better. Plus, of course, some of the other things like size of tabs, line numbers, often even syntax highlighting. But finding out how to deal with plugins, themes, settings, etc. is difficult when you aren't already introduced to Vim, precisely because most people make the assumption that you've learned Vim "as is" already.
I think some concession has to be made to modernity. Vim is very old and "as is" it often just doesn't function very well for everyday use. Grinding through that until you know it well enough to be given the knowledge of how to make it nicer to use isn't worth it to most people. It certainly wasn't to me.
I can't recommend this book enough. As a long-time Vim user, I still learned a few things after reading this book. Drew Neil is a pretty awesome person too.
I disagree. Vim is bare, cold, and strange when coming from a traditional editor, and I probably wouldn't have gotten involved if it were not for a friend who already have a useful .vim and .vimrc for me to use as a starting point. He got me up and running with a Vundle, syntax highlighting for all my languages, autocomplete, and various settings that should have been default with stock vim. Though vimtutor was also very useful for getting used to the standard controls.
Edit: Forgot the most important thing, the setting that lets you use the mouse: set mouse=a. After I discovered this I knew I was never going back to Sublime.
I avoided vim for years after being introduced to vi at university, not realising vim could be customised to be much more comfortable and modern feeling.
I started out trying to go plugin free since I wanted to avoid bloat, but eventually gave in once I found plugins that eased bottlenecks in my workflow with a barebones vim.
Though I love the plugins I use now, I do agree that it makes sense to be fairly comfortable in a plugin-free vim before installing a ton of them.
I wrote a blog about this topic a month or so back:
I agree and then I got a little mad. My version 1 is outdated and the updated ebook is a full price cost for me. Why are some ebook companies charging full price for revisions of books purchased?
I always thought that if I were ever to write a book on vim, I'd start with a thorough introduction to ed, followed by a thorough introduction to ex, finally followed by a thorough tutorial on all the features of plain-old vanilla vi, only then to introduce the vim parts and macros and graphics and things.
No, not sarcastic at all - I just didn't think anybody besides me would be crazy enough to want to read such a detailed treatment of an old text editor. Guess I'd better get started writing ;)
It took me a while to realize what really vim is for. What led me to realization was switching to Emacs. I read this post, and second checkbox says "modern customizable IDE". And I stopped there. Why you may ask? Well, I used Vim for 3 years before trying Emacs this spring. And I loaded it with all the heavy plugins(YCM), but Emacs led me to realization that Vim is more of an editor than IDE. Even with plugins I think it just doesn't even come close to Emacs, which has really nice ecosystem and plugins that are spot-on IDE feeling (ENSIME, CIDER, Alchemist etc). When I configured Vim again few days ago I realized how I misused Vim. My init.vim had about 150 lines of code, with few plugins, and now it felt right. Just like it felt right to customize the living hell out of Emacs. Again, this might be just my perception of things, some other people like it the other way, different flavors for different people, but it is how it felt right for me personally, after trying to understand philosophies and surroundings in which these wonderful pieces of software were made.
My feeling is that real value of Vim is its novel approach to modal text manipulation, and you shouldn't let the fact that it has a standalone lightweight reference implementation usefully installed on almost every machine that you use confuse you.
Vim script is not a great plugin language, and the vim runtime itself is not fantastic at doing things beyond the text editing. I think the activity around NeoVim is good evidence for this. The community recognizes the constraints of Vim, and seeks better plugin and runtime tooling to meet their needs.
My issue is: there are loads of great text editors that support the Vim interface. Emacs, Atom, Sublime, whatever, all have very good Vim interfaces and far superior languages and platforms for doing complex plugin work that you need to support IDE-ish environments. NeoVim seems like a bit of a waste to me, because I think it misses the point. Vim is not a platform. It's a unique modal editing paradigm. Why make yet another Vim-binding-having platform?
I guess what I mean is that vim should be left as vim. There are superior platforms that implement the same interface, should you feel the need to expand your tools. Vim does best as a portable minimal editor that you can use everywhere. If you need something with more power, pick a better platform, and run the Vim editing paradigm as an interface.
> NeoVim seems like a bit of a waste to me, because I think it misses the point. Vim is not a platform.
Neovim is designed to be hosted (embedded). Embedding Neovim in a IDE (platform) allows Neovim to be the editor while exposing the IDE as "the platform".
It's also a guiding principle of Neovim to not dictate what applications are built with it, so yes, you can leverage its API as a platform. But that's not the singular purpose.
> I guess what I mean is that vim should be left as vim. There are superior platforms that implement the same interface,
There are no applications that implement Vim (except Neovim, which passes Vim's test suite).
What's the process of embedding neovim into something like xcode? the thing that always got me confused is how the IDE would handle the text changing on an open file like that. What's the flow expected to be?
I'm guessing some kind of event system out of band that the IDE can hook into. Using the OS for that is probably too low level to provide the experience people expect. https://neovim.io/doc/user/msgpack_rpc.html
> There are superior platforms that implement the same interface
I guess that depends on how well you know Vim.
All of the Vi/Vim plugins and emulators I've tried fell in the "uncanny valley" where they were only superficially like Vim but sooner or latter departed from the expected behaviour.
Yeah, fair enough. That's a very good way of putting it, and I know exactly what you mean.
I think the hardest part about implementing the Vim keybindings is that they're intrinsically linked to the way that Vim models text and operations. Commands are really statements about this internal model. Without the model, it gets difficult to reproduce the full palette of vim commands with very high fidelity.
You kind of inevitably have to build your own vim-like text model to handle the keystrokes, and map it back into the platform that you're on (which is often a dumb buffer object for most text editors.) It's certainly much deeper than a keybinding. I called it an interface, but that's still not really deep enough.
you might want to give spacemacs a go... it's quite good after you translate whatever vim config to emacs config. out of the box it's actually quite great and this is coming from a hardcore vim user that can't stand using a text editor without vi bindings and proper macro support etc. Everything is done pretty well and there isn't anything that I have found dealbreakingly lacking so far.
I know about spacemacs, and don't like the idea of core editor. Tried it and ended up using not emacs, not vim, but mix of both, and commands from both. And I do not like that.
I had the same experience. I love the idea of the space leader and the mnemonic keymappings, but too much of Emacs leaked through.
I've taken the lessons learned from Spacemacs and applied them to vim, remapping the leader to space and using mnemonics for remapping of some commands — all the markdown based commands are under space m, for example.
I had my leader set to spacebar in vim and used mneumonics for the bindings already, but the main thing other than the discovery of forggoten leader keybindings(how many can you really remember even with mneumonics?) that I dislike about vim is how almost every extension just feels broken and hacked together. there are some that work well but a lot of them are just crap and I attribute that directly to extension authors wanting to use viml as much as possible to keep maximum compatibility and reduce external dependencies. Lisp is a good language that is self documenting as well as being usable. viml is a terribly hacky language that is awkward at best and counterproductive at worst. I still love vim but vim needs a better language around it. perhaps when neovim picks up steam the lua backend will lure people to write good plugins in it.(lua is a pretty good language overall). just depends on who wins the war now between vim and neovim now that vim has better async support.
I'd disagree that vim script is not a great plugin language, it's php like in it's simplicity and has a few novel features (like scopes) that are ideal for text editors and wouldn't fit into the variable scoping rules of other languages. Now it finally has a thread/process model too, making it better than ever.
Creating a user specific script in vim is an order of magnitude simpler than atom.
I don't think it's true that vim "just doesn't even come close to Emacs". They each have their strengths and weaknesses.
As bad as the defaults for vim are, they're even worse in emacs (IMO) -- especially for former vim users (though I haven't tried spacemacs, which is supposed to make things automagically a lot more comfortable for people coming from vim). Evil mode helps a lot, but even with evil, most commands in emacs and its modes remain bound to traditional emacs chorded keystrokes, not to vim-style moded keystrokes (the latter of which feel much easier on the hands for me).
I've used vim (vi and some other vi colones before that) for over 25 years, and switched mostly to emacs (with evil) about 6 years ago or so (while continuing to use vim on servers that didn't have emacs installed).
I spent several months, spending 10 hours a day to customize emacs the way I liked it, and to bring it mostly up to parity with my vim config (which was thousands and thousands of lines long), along with customizing some emacs extensions that had no vim equivalent (like emacs-w3m, which is an embedded web browser, which is still super handy despite not working with javascript). It took that long despite me knowing Common Lisp and scheme before switching to emacs, which made learning Elisp a breeze compared to the extra effort it would take someone coming from vim who didn't know any Lisp.
And still, even after all that work, I haven't gotten around to learning and customizing many of the things I really want to use emacs for, like email, IRC, RSS, Slime, and the various other extensions made for editing Lisp and Scheme.
So I found the switch to be a ton of work, which was worth it for me, since I'm still using emacs instead of vim, and don't intend to switch back. But others who are considering a switch from vim to emacs should also be prepared to do a lot of work customizing emacs to your liking. It's a never-ending process, really, just as it is with vim.
Now some words on some of what I see as strengths and weaknesses between the two editors:
Vim has much better tab support out of the box. Emacs has any tab support without extensions, to my knowledge.
Though vim's methods for writing syntax-highlighting for new, not already recognized filetypes is a bit of a nightmare, I found it to be a lot easier to understand than how to write new modes in emacs -- which I still really haven't bitten the bullet and fully learned. So for some filetypes that emacs doesn't have modes for, I still use vim to this day. This is particularly the case for strace output, which I view pretty regularly in vim, which handles them just fine, but emacs still has no modes for.
One of the main reasons I switched to emacs was for its allegedly superior shell/terminal integration. But I found it really lacking for anything that involves curses terminal graphics, and also not really practical for me since I don't use GUI emacs, but rather use emacs inside tmux and inside a terminal. This makes for way too many levels of indirection for commands, and a lot of keystrokes are taken up by the various levels. Some say I should just use GUI emacs and not use tmux, but I don't want to do that, and am not going to go in to all the reasons why, in the interest of not making this post much longer than it already is.
Emacs has a huge win over vim (for a Lisp/Scheme lover like me) in being natively scriptable in Elisp (and perhaps soon in Guile Scheme). vim could be scripted in scheme, but 99.9% (or more) of vim scripts aren't done in scheme -- the ecosystem is really mostly vimscript, which I don't hate like some people do, but which still pales in comparison to "real" programming languages like Python or Ruby, and even more so compared to a Lisp or Scheme (IMO). While virtually the whole emacs ecosystem is written in Elisp. That's super important to me, and makes writing and reading my emacs configs and emacs scripts a lot more of a pleasure for me than scripting vim will ever be. When mainline emacs switches to Guile Scheme, scripting it will be even more fun for me, and this Lisp ecosystem is one of the primary reasons I will continue to use emacs instead of vim in the long run.
vim has neovim, which is super exciting, and has even made me (on occasion) wonder if maybe I should switch back. The ability to completely and cleanly split vim between the controlling and presentation levels and to properly and fully embed it in other programs is going to be huge. Emacs still has a lot of catching up to do in this area, despite it having a server mode, which does help.
emacs can be really super slow on some large files that demand a lot of syntax highlighting. vim has the same problem, but to a much lesser extent. There are times that I'll switch back to vim just to edit some huge files every now and then. In such times, I must say that it's nice to be comfortable in both editors, so I have a choice as to which to use as the situation warrants.. the right tool for the job, and all that.
As I mentioned before emacs-w3m (a web browser embedded in to emacs) is really great, and I use it all the time, despite it not being able to handle javascript. It's awesome to be able to split a web page in to panes in the same and independently scroll each pane, and to copy and paste things in to the panes without leaving the editor. It's super handy for browsing several sections of online documentation at the same time, without having to split out the page in to seperate windows in a traditional browser. I also use pentadactyl in firefox, and while that's pretty cool as far as it goes, it still does not come close to the power of having the browser embedded in an editor as powerful as emacs, and vim doesn't have anything close to that, to my knowledge.
Similarly, there are emacs extensions for full email, IRC, and RSS clients, which sound awesome and don't have vim equivalents, to my knowledge. But I haven't tried those, so can't comment.
There are many more things that one editor or the other is better at. But I'll just end this here, so I don't make this post much more ginormous than it already is. This subject really deserves a blog post or even a series of them, and maybe I'll write one.
> (while continuing to use vim on servers that didn't have emacs installed).
Curious, why wouldn't you use Tramp mode for that? I've found that to be a much more satisfying experience than the whole fire up terminal -> ssh somewhere -> poke around with cd -> fire up a vanilla vim song-and-dance. Instead, simply open the remote file with your entire editing environment still available, plus potentially even the superior Helm or Projectile or whatever you use available instead of manual file-finding.
I never really got comfortable with TRAMP mode. Maybe I'm just too set in my ways, but I like to navigate directories from the shell, for the most part, and issue commands (including invoking editors) from the shell as well.
There some exceptions, such as when I use Midnight Commander to navigate and perform some common operations, but for the most part I like the shell. (By the way, I know emacs has dired mode, but that's something else I haven't invested the time to customize to my liking, and until I do, it will be very underpowered and unintuitive compared to Midnight Commander, for me).
I do use Helm in my local emacs sessions (though mostly just in the current directory, or for functions other than file-finding), and like it, for the most part -- except for the tons of bizarre and inconsistent keyboard commands, and don't like that it's super slow for me for some reason. I really can't wait for Emacs to move to Scheme, so hopefully its performance can greatly improve as a result.
I wish I could use vim or emacs. I don't know if I'm stupid or something but all of the key bindings, everything you have to remember, it just doesn't make sense to me.
I wish there was something like nano + plugins. If I had that I could implement most of what I need (other then auto-completion for a crap load of languages).
Learning Vim is probably a bit like learning to bicycle/swim. It requires a lot of conscious effort at first but eventually becomes a second nature. Also, I doubt many vim users would use "nano + plugins" if vim suddenly disappeared. The fact that vim has many plugins and runs in the terminal is nice but isn't the main reason people use it IMO.
I second the suggestion of using vimtutor to get started (uninstalling other editors helps too!).
There's something to that, yes, that a lot of things become second-nature (e.g. once you learn Vim, when you're in Nano on an unfamiliar machine, you start finding yourself accidentally typing Esc-:w to try to save a file).
There's also something about "this is totally unfamiliar and not at all incremental upon what I know." I was vigorously against vim after trying to do it many times, eventually I found out a base set that allowed me to learn incrementally, now it's not so bad. The big thing is to totally forget all of these people who are saying "vim is like an awesome language for text editing." Maybe it is, but that's an awful sales pitch. This person wants to spend a few minutes editing source code, not spend a year learning a new language.
The minimal starter set for Vim is something like:
# From Command Mode #
dd | deletes a line
. | repeat whatever you just did, for example pressing I,
then the delete key 4 times, then Esc is one command
which dedents a space-indented line by 4; now you
can go down a block hitting . at each line to
dedent it.
i | switch to edit mode at present cursor
I | edit at beginning of line.
A | edit at end of line.
u | undo
Ctrl-r | redo
From there probably the next thing I would teach people is brace jumping with %, regex-jumping with /, visual-lines mode shift-V and either cutting with d or copying with y, then pasting with shift-P. Finally macros with qp ... q ... @p. After that, maybe dealing with multiple buffers. Just let people use the arrow keys to navigate, don't get too religious about the home row or letter repetitions like d5d.
I think that's a basic skillset that will let you say "okay, my thesis advisor is making me put two spaces after each period that's not an abbreviation in this document, what editor should I use for that? Well I want to step through everything just to make sure, but let's just use Vim where I know I can write "fix this one and then jump to the next period" as a macro, and interleave that with some basic navigation when it's not right."
the problem with learning vim is that it's like learning to bike by biking to work. most people use vim when they code, and they code at work, so using vim is directly in the way of getting any productive work done.
i was just one of the ones stupid enough to waste two weeks of productivity to learn a new tool lol
I managed to stack learning vim with normal on-boarding related slack by picking it up on my first day at my first coding job. IMO, one of the top ten decisions I've made in my life.
Same, using vim "full time" was what really made me learn and appreciate it. Before that it was just something I would occasionally use when making quick edits on a server.
Vim is very easy, I think it's just simple to get overwhelmed with it.
There are a couple of tools which gamify Vim. I personally haven't used them. But some say they're pretty good.
For me, what worked was just jumping in and going whole hog. I tried disabling the arrow keys in Normal Mode, so I would have to use hjkl for navigation. But my keyboard puts the arrow keys in easy reach (Kinesis Advantage), so it turned out not to be much of a need.
What you may like is turning on relative line numbers. That way you can visually see what line you're at, and how many lines away your target is that want to jump to. Then you can practice going 5k to go up five lines, or d2j, to from where you are to two lines down.
I wrote a shell toy to help me learn vim motions.. the idea is you can grab parts of the output of previous shell commands by passing vim motions. So like when you want to say "git checkout <that branch mentioned 5 lines up in the previous command's output>" you can do it :)
git checkout $(lw 5kyiW)
It's more of a toy than a power tool but I do use it somewhat regularly.
For bash or any other application using the readline library you can configure it for vi mode by adding 'set editing-mode vi' to your ~/.inputrc. Note for bash you can instead add 'set -o vi' to ~/.bashrc to avoid setting the mode for all readline applications
It's an extra thing to remember. When I'm coding I usually just do :w, so when I'm editing config files I do :wq because it's the same thing (write the file) plus a new action (quit) in my head, instead of a totally different action (save and quit)
Vim takes a while to grok. You have to move away from the mindset of "memorize a lot of strange commands" to the mindset of a language for text manipulation. Then, learn the absolute minimum set of commands ([a]ppend, [i]nsert, [d]elete, [p]aste), start using, and add vocabulary gradually. Just like learning a new language.
As others have said, start with the basics and learn to use the help system. I found it enormously helpful to watch videos like Derek Wyatt's[1] that show a Vim master at work and explain the basics. It's not that I learned the key mappings from watching videos, but I did learn the potential of Vim.
Then, with a basic understanding of how to use Vim as a beginner and a comprehension of the possibilities, I paid attention to how I worked and looked for areas for improvement. When I spotted something that I could do more efficiently, usually reducing repetition, I used the Vim help and Google to find out how to do it.
A trivial example would be using the hjkl movements to go further than a couple of characters. First, I learned to move in words (w and b), then I learned to use the f and t searches and incremental searches. Then using counts to move specific numbers in whichever direction. After a month I stopped reaching for the mouse or doing llllllllllllllll to move through text.
I learned slowly: maybe adding one cool key mapping or feature to my workflow every couple of weeks. After a few months, it adds up. Soon you don't even think about it. You see what you need to do and your fingers do it for you.
Vim is a complex beast: an accretion of decades of features, most of which you'll never need. The best way to learn is by the same process of accretion. You'll start off using Vim like a non-modal editor, but if you stick with it, your patience will pay off.
In emacs, at least, every command has a name. Anything you'd like to do can be searched using tab completion and a little guesswork, at first, by typing `alt-x` followed by the first couple letters of a plausible name for the thing you are trying to do.
It's an extremely clumsy but totally workable way to get around if you only rarely need to edit a text file on a remote server. For example, if you highlight a section of text, you can `alt-x comment-region` and emacs will automatically insert comment markers at the beginning of each line (`uncomment-region` to undo the process). Or `alt-x save-buffer` to save.
The myriad keyboard shortcuts are just aliases for the named commands, so it's a straightforward transition from the clumsy tab-complete workflow to a more efficient one once you know your way around.
It's heavier than Vim and a fair bit of Emacsy stuff leaks through. It's a great project, but I prefer Vims way of doing things. Also I have a bunch of custom Vim functions for doing stuff like invoice generation and I didn't want to reimplement them in Lisp.
Just curious, what editor(s) do you use? I was using Sublime Text, and for the hardest part of switching to Vim was feeling the huge productivity drop in the beginning as I relearned how to do everything.
I weaned myself off other editors by using vim for thought-intensive programming. When most of your time is spent trying to come up with efficient solutions to your problems, spending a little time learning more about vim isn't so bad... and can be a welcome distraction.
I still use editors like atom for web development where I go through frequent iteration cycles and make heavy use of the clipboard.
I used sublime for a bit, but I didn't like getting nagged. Right now I'm using some JetBrains products and Nano.
I sketch everything out into nano, then I pull it into CLion when it's ready to be cleaned, updated, iterated, and in general changed to become a "final" version.
I use Sublime (happily staying here as well) but I use vim still for tiny editing very now and then. I'd recommend learning just moving around (I use arrow keys). A for append to end of line, I for insert in beginning, dd for delete line, i for insert mode, wq for save and exit. Maybe 5up/5down etc for faster navigation.
This is pretty much what I only use. I feel quite comfortable with vim and if I ever feel like I want to learn more, knowing how to do these super basic steps feels like a solid ground.
If it helps, I learned vim by following the most basic tutorial at first (vimtutor), learning how to navigate, save my changes, switch between command and insert mode, and not much more. I then forced myself to use it.
vim's defaults are, honestly, terrible. So you'll quickly run into lots of little frustrations. For each one, I'd look up potential solutions online, and if I could find a solution which was intelligible to me given my level of understanding of vim at the time, I'd use it.
Eventually, some of those solutions involved using plugins.
After a few months, I found myself culling plugins that I'd installed as I learned better solutions that either weren't intelligible to me earlier or were just too overwhelming. For instance, NERDTree is an early plugin I used, but I eventually reached a point where I never touched it, so I removed it.
Try out Vim Adventures to get some basic commands down. Then find Vim emulation for your editor of choice. Leave it in insert mode as much as you need at first. Slowly you'll start using more Vim commands. In a while you'll wonder how you ever edited without it.
I second the recommendation for Vim Adventures. The free part is fun, and being forced to work with a subset of features as you acquire more gives you a better feel for when they're appropriate.
I assume the non-free bits continue in suit, although sticker shock prevented my finding out. For someone benefiting beyond entertainment, it's likely worth it. As a long time vim user I had trouble justifying it.
I started out like this. In effect in the beginning you can do everything in edit mode, you don't actually need the key bindings. Pretty much the only thing I learnt was 'dd' to delete a line (which actually just cuts the line).
The other very simple thing is just typing '/' and then searching. It's much simpler and more natural once you're used to it than Ctrl+F. Then further searching is just hitting '/' again instead of F3. Firefox has the same command that you can use, just hit '/' and you can start searching.
Underlying this though, is a very useful and powerful editor that's there and waiting for you to use if you want to invest the time.
I come from a Windows world so wrote up a table of comparable commands [1].
Edit: It is also pretty cool however, that if you install Vim on Windows (it gets installed as part of Git) and with a bit of Solarized colours [2] you can get a IDE level editor in your DOS prompt [3]. It blew my mind anyway.
Probably what you're looking for is gVim-easy which is installed along with gVim. It starts in inset mode and the menus give you some idea of the shortcuts available. gVim should also respond to OS shortcuts like C-c, C-v, etc.
Suppose you have two identical codebases that each need to have the same 200 lines changed. Functions need to be added, comments to be removed, templates need modifying, and so forth. In one of the two codebases, you use Nano to apply those changes. In the second codebase, you use Vim. Assuming the Vim user was proficient at Vim, you can be sure that he/she used 1/3 -> 1/2 as much hand and wrist effort than the nano user to make the same changes. It could be that the effective Vim user ended up using less than 1/2 the hand effort than the nano user.
If you extrapolate this over these two coder's careers, you realize that the Vim user is going to be glad he spent the time learning Vim.
Learning how to use Vim has been so rewarding for me. I love coding in Vim and I love learning new ways of doing things.
> Suppose you have two identical codebases that each need to have the same 200 lines changed. Functions need to be added, comments to be removed, templates need modifying, and so forth. In one of the two codebases, you use Nano to apply those changes. In the second codebase, you use Vim. Assuming the Vim user was proficient at Vim, you can be sure that he/she used 1/3 -> 1/2 as much hand and wrist effort than the nano user to make the same changes. It could be that the effective Vim user ended up using less than 1/2 the hand effort than the nano user.
> If you extrapolate this over these two coder's careers, you realize that the Vim user is going to be glad he spent the time learning Vim.
This I completely understand, and if I was a professional programmer who had to deal with those sorts of operations regularly I'd probably find Vim very rewarding to learn.
The perspective I come from is that of a sysadmin. If I'm editing large amounts of text I'm probably on a system where I control what's installed and thus can have whatever editors and IDEs I want, within reason. The situations where I find myself forced to use Vim are stripped down appliances where more often than not I'm looking to make a single change in a single line of text.
For that use case basically any editor with a working find feature is equally fast, so I'd much rather have one that uses a standard or at least discoverable user interface.
To me Vim is like one of those simultaneous torquing machines used in modern vehicle assembly plants, where I'm just looking for a torque wrench to check my lug nuts.
I hear you for nano, but what about compared to [graphical mouse-clicky editor of choice] (in non-vim mode)? I know enough of the basic vim commands that I could edit a file if I ever needed to but how much hand effort could it save me vs. kate or VS Code? (though i really prefer notepad++ to both of those) I feel relatively efficient in a good graphical editor but maybe I just don't know any better? Really just give me reasonable multi-selection features and I'm happy.
To prove that Vim is faster than a graphical editor as well, I might make a WebM where I edit two identical files, one with notepad++ and one with Vim. Would you appreciate that? I will do that if you respond to this.
There's a plugin (can't remember the name of it right now) that lets you use mouse controls as well. Click where you want the cursor, scroll, click on which tab you want, etc. That was game over with Sublime for me.
I spent the last 2 hours of every work day using VIM, regardless of how much longer it took to work on things. By the end of the week, I could jump into vim after lunch. When I started using ':x' in TextMate I knew it was time to leave.
Upon seeing the headline I was hoping this was a reworked version of Vim that was more intuitive, that didn't require the user to learn all the secret handshakes and voodoo recitations to get things done.
it would be cool to be able to open
files without having to do File -> Open
using the menu bar
How about using the :edit command?
> 3.5.1 Plugin manager: Pathogen
> 3.5.2 The NERD Tree: a file explorer
The NERD Tree is a plugin that will
allow you to display your directory
and file tree directly in Vim
> 4.1 Learning how to move
Most distributions of vim include the netrw plugin for remote and local directory browsing. Do we really need to learn how to install plugins before even learning how to navigate within a file?
This book seems to focus on the basics of vim. Unfortunately, it falls into the common trap of piling on many layers of unnecessary extras before explaining the basic details. I would not recommend this resource to a beginner.
Your opinion is quite common with old vim hands, but I would have to respectfully disagree.
Someone learning vim is probably coming from Atom or Sublime. The defaults in vim are so egregiously awful, that I don't think you can expect these folks to stick with learning. Their productivity drops to zero - there isn't even syntax highlighting - so they give up and go back to what they were using.
You have to get vim to a point where they can be sort of productive, if you want them to stick with it. I think some customization is necessary for beginners.
An alternate idea would be to use neovim, which fixes many of the defaults.
I switched to Vim as my primary editor about two months ago. I remembered how much easier Emacs Live[0] had made my life when I was giving Emacs a serious go a little whole ago, and found a sorta-equivalent for Vim[1] which smoothed over a lot of the rough edges and put in some of the modern convenience an ST die-hard like me would expect (autocompletion, package management and what have you).
That left one remaining barrier, which is the weirdness of modal editing; which is the important barrier, because the only reason you'd use vim is to sign up to the pre-eminent modal editor.
Maybe, two new laptops from now, or one lonely weekend, I'll take a hacksaw to spf13 and strip out the bits I don't need. But for a shallow onramp experience, it's been a godsend.
A little background. I am familiar with vi and use it only when I ssh into a server.
But I never really felt it was more convenient or an improvement over a GUI based text editor or IDE on my development machine. Eg- gedit for simple text editing, Android Studio for android development, Atom for python coding. Everything works out of the box with minimal tweaking required.
Genuine questions:
-At what point on the learning curve do you feel using vim is an advantage for speed of development, if at all?
-The common argument of only keyboard, no mouse when using vim... I don't get. Is using a mouse such a major factor that slows you down or affects you negatively?
My simple whys. No mouse needed is the biggest. It is like when you watch someone not use short cuts in your OS or they use mouse to select the word and then right click for copy.
diw to delete whole word.
yy then 5p to repeat the line 5 times instead of copy paste.
/ for search is really nice.
gg to go to the top or G to go to the bottom.
These things make it worth using vim for me. I use vim mode on all the editing programs (RStudio and VS Code)
But most modern editors have similarly efficient shortcuts for all those things that fit alongside modern UI shortcuts. e.g. in Sublime:
<Ctrl-D><Bksp> to delete a word.
<Ctrl-Shift-D> to duplicate a line. [0]
<Ctrl-F> for search.
<Ctrl-Home/End> to go to the top or bottom.
I'm increasingly unconvinced that vim has much to offer in terms of shortcuts when compared to actual modern editors, rather than some kind of strawman notepad.
[0] No numeric repetition, but I was never convinced by that feature TBH. In most cases, the mental overhead of working out the appropriate number for a situation was greater for me than just spamming a button a few times.
The biggest thing with vim is it provides a language for actions rather than individual actions itself. This allows for far greater action control than a standard editor via shortcuts.
For example, maybe you need to delete the next two words (d2w - delete 2 words). Or maybe you want to delete the next four words, then replace them with something else (c4w - change 4 words). Or maybe you need to change the every letter of the next ten lines to uppercase, until you hit the letter 'a' on each line (qq0gUtaj10@q).
VIMs shortcuts aren't better because they're more powerful, they're better because there's an infinite combination of them.
As I mentioned above, I'm not really convinced that numeric repetitions are that useful, because counting instances, even at a glance, is more mental overhead than just pressing a button a few times. Because most of the time I don't want to "delete n words", I want to delete these words, and there happen to be n of them.
More generally, my experience of vim is that I'd spend longer working out how to do something with one command than I'd have taken to just use a few simpler actions. And that didn't really get better with time (I used it as my primary editor for a few years), because sufficiently complicated editing tasks just don't arise that often.
And personally, I find Sublime's multiple selections much easier to apply in ad-hoc ways to unusual editing scenarios than vim's vocabulary.
A common scenario I encounter, is that I realise I need to make a change in many matching places, but I don't know immediately whether it applies to the entire file, or whether there are some edge cases. In Sublime, I select one instance, step through adding matching ones to the selection and excluding any I don't want, and then make the edit confident that I'm changing exactly the things I want to.
In vim, my experience was that I'd write a substitution, discover it was too general when it broke something, and then try to work out how to exclude the cases I didn't want, which was often nontrivial. EDIT: Thinking about it now, I guess the vim way to do the above would be to / for the first case, make the change in insert mode and then use /. for the others. Although if it's a complicated edit, it might not be effective to use insert mode, so I'd need a macro maybe? I found those kinda fiddly tbh.
It's not just repetition of say, do this command more times to words. There are more nouns available to apply your verbs to. You can "change a paragraph": `cap`, change the contents of some brackets: `ci(`. I find myself using various permutations of these all the time, and missing them enormously when I'm not in vim. My favourite is `caa` to change an argument in a function call, respecting commas and parens, although that one came in a plugin I think.
I completely agree that often figuring out how many words I want to apply a command to is too much effort; however of course vim has visual selection like any other editor, so I can just press v to begin selecting, then w a few times to move to the beginning of the next word, and then I can apply any of the verbs in my arsenal to the resulting selection.
I find that having the option of <count> repetition is much more useful with large text objects that I can easily subitize. It's very natural for me to delete 3 paragraphs with `d3}` for instance, moreso than selecting them then deleting them.
I think that my very favorite motion in vim might be the `f` key. You use it like `fj` to move to the next occurrence of 'j' on the current line.
I also agree with you that multiple cursors are a much better solution than regexes to the same edit in a few different nearby places. There are multiple selection plugins for vim, but they don't work very well, and I wish it had better support. On the other hand, regexes scale much much better.
Except those don't make much sense as compositions, because they overload the letters. cap? What does change-append-paste mean? Oh it actually means change-a-paragraph? Okay...
Sure, there are some convenient patterns to vim's shortcuts, but I think the extent to which they're a "language" is overstated. And that's fine, since it's mostly about muscle memory anyway.
>I think that my very favorite motion in vim might be the `f` key.
Yeah I did miss that one for a while.
>On the other hand, regexes scale much much better.
If I want regexes, I can use find and replace with them. And I think the minimal (keyboard driven) GUI is a lot easier to use for that than s/// syntax.
I have been using VIM since I had a floppy disc of it on my Amega I got from my dad. I will say I don't use VIM all the time and right now I am loving VS Code but in the end I always am using VIM modes in whatever editor I am in. RStudio or VS Code.
>-The common argument of only keyboard, no mouse when using vim... I don't get. Is using a mouse such a major factor that slows you down or affects you negatively?
Yes, it hurts my wrist. If I use it continuously for too long it becomes disabling. I use awesome window manager, tmux, vim, vimium browser plugins so that I never have to touch the mouse.
Keyboards hurt my wrists too but it's much more manageable.
I havn't measured actual speed/efficiency, but once I got used to keyboard shortcuts for everything using the mouse feels slow, clunky and inaccurate.
The best comparison I have is: You know how when you are helping someone that doesn't know how to use a computer? How frustrating it is as they slowly mouse around, looking for stuff - makes you wanna just sit down and take over?
Well that's how I now feel when someone else is editing a file without Vim.
> -At what point on the learning curve do you feel using vim is an advantage for speed of development, if at all?
Text editing is not a bottleneck in my development workflow, so I'd say never. This said, I wouldn't change to a different editor, especially one that doesn't have Vi-like modal editing.
> Is using a mouse such a major factor that slows you down or affects you negatively?
Yes and it's also an ergonomics disaster.
Vim isn't great when it comes to IDE-like features but it's a great text editor once you grok the paradigm. If you use it like a "normal" editor, it kinda sucks. Once you can keep your hands on the home row at all times, you don't want to go back.
Vim's killer feature, not found in any other editor I know, is repeat (.) .
I use vim in tmux with a curses debugger and it gets a lot of IDE benefits but is language agnostic. Changing to a different editor/IDE depending on language/target platform/project just sounds awful.
Well, it depends on what you're doing. For example, if I want to duplicate a line in vi, I can type 'yyp' and _bam_: duplicate line. With a keyboard and a mouse, I have to reach over, select the whole line (being careful not to over or under select), hit Ctrl+C, move the cursor down to the beginning of the next line, and hit Ctrl+V. If I want to change the contents of a quoted string, I can type 'f"lct"' and start typing. Again, with a mouse, I have to select what I want to change: if I select too much, I can back up the mouse, but if I accidentally started the selection on the second rather than the first character, I have to abort the whole selection and start over again. If I want to change each line from the current line to the next blank line to a continuous quoted string, I can type ':.,/^$/s/\(.*\)/"\1" +/'. With a mouse, I have to click the beginning of each line and cut+paste the quotes into place, probably undoing at least a couple of times because I clicked the wrong place, etc. etc.
I know, I'm talking about milliseconds (or nanoseconds) here, but when I use vi, it's just, sort of "constant", like playing the piano. I never break my rhythm.
> With a keyboard and a mouse, I have to reach over, select the whole line (being careful not to over or under select), hit Ctrl+C, move the cursor down to the beginning of the next line, and hit Ctrl+V.
Sure, but who does that?
In any text editor on the Mac its:
- Command-Left to move to the beginning of the line
- Shift-Command-Right to select to the end of the line
- Command-C to copy
- Command-V to paste
One annoying thing about that, though, is that it doesn't copy the newline itself, so if you want to paste the line and the line terminator multiple times, you need to do something more like:
- Command-Left to move to the beginning of the line
- Shift-Command-Right to select to the end of the line
- Shift-Right to select the newline
- Command-C to copy
- Command-V to paste
But, of course, most full-featured text editors make that easier. In Sublime and Atom, it's:
- Command-L to select the current line
- Command-C to copy
- Command-V to paste
- [2] Command-Left to move to the beginning of the line
- [3] Shift-Command-Right to select to the end of the line
- [2] Command-C to copy
- [2] Command-V to paste
Total keypresses: 9
Total keypresses for yyp: 3 (4 if you have to esc to normal mode first)
My point being that even the simple and straightforward actions you provided are more complex than they seem.
Firstly, that's 6 keypresses, because you don't need to lift your finger off Command.
Secondly, that's just using the minimal set of shortcuts that work anywhere. If you're in an actual editor, it almost certainly has a shortcut like Ctrl-Shift-D for duplicate line.
And I think a lot of vim users might be surprised how simple and straightforward things can be in a modern editor.
Sublime, at least, has a duplicate line command. I believe you can also use the copy command with no text selected to copy the current line. None of your examples seem nearly as effective as pressing yy to copy the line and p to paste below.
How composable are those commands? The best thing about vim is that it works with text objects, so yy will select a line but yw will select a word, yip select a paragraph, yi( will select in the function call, etc.
Similarly, if I want to change them or delete them the y becomes a c or d.
```f"lct"``` can just be changed to ```ci"``` and it will do exactly that with fewer strokes and is easier to remember and more resistant to where you are wrt the first double quote. (can be remember by change inside ") if you are inside a double quoted string already it will still work correctly and if you are before it on the line it will search forward for it and change the same string.
works with ( and { and ' as well. also, ```ca"``` will do the same but include the " in the change. (change around the ")
not sure if it's built into the stock vim but ```cit``` will do a change inner tag for html and xml tags too.
Well sure, if you compare vim to some kind of strawman notepad user it's gonna look pretty good. But if you compare it with someone who's put a fraction as much effort into learning a modern editor, the benefits seem a lot more dubious.
e.g. in Sublime:
>if I want to duplicate a line
Ctrl-Shift-D
>If I want to change the contents of a quoted string
Ctrl-Shift-M selects inside parens. It doesn't do quotes by default, but there might be a way to enable that.
EDIT: I looked this up afterwards, and discovered Ctrl-Shift-Space selects a quoted (or parened) block, although it includes the quotes.
>If I want to change each line from the current line to the next blank line to a continuous quoted string
Okay, this seems a bit contrived, and I'm not convinced the average vim user would bother with this rather than just doing something like I"<Esc>}kA" or whatever.
Unless you're bulk editing, in which case I think Sublime's regex find and replace would be similarly effective, and probably easier to get right than typing the whole command in one.
I will note however that selecting text and pressing a paren key wraps it in parens, and as above it might be possible to make that work for quotes.
I have replied to the other commenting wondering about Vim but I will say it here as well: Learning to get fast with Vim is incredibly rewarding. It is tough to memorize everything, sure. But it's all in pursuit of speed and efficiency that become huge multipliers over your career. You use so much less hand effort, and it runs straight from the terminal which means you need fewer running applications.
After watching Bret Victor's talk https://vimeo.com/67076984, I feel like Vim way of using computers is backward. I am probably wrong because I never got proficient with Vim. Using it only when I SSH to remote server.
It took me about six months of using vim every day to feel like I was as efficient as I had been with Textmate or BBedit (the best options available to me at the time). I was already very agile using the keyboard shortcuts in BBEdit and other Mac text editors, but now for text editing I really do prefer vim's modal style.
And yes, after having been using vim 95% of the time for a few years, it really is faster to keep hands on the keyboard instead of using the mouse. MacVim lets you point and click to position the cursor, just like any other text editor. I almost never do, though.
In college I used something like 10 systems on 6 networks of which I had control over 2. VIM was already everywhere, that's when it's worth learning. When ubiquity is a compelling feature
I just recently switched to vim full time, maybe 4 months ago, after my existing IDE switched to a subscription model following two updates that made the software more and more buggy. I don't have definitive answers, just experiences:
1. The first two weeks were hell. It felt like learning to use a keyboard all over again. I've tried to get started with vim multiple times, leaving because I needed something faster. This time, I just happened to catch a break in work where there was no one breathing down my neck to get stuff out the door yesterday.
After two weeks or so, you start to learn the vim mindset. It's hard to explain, but vim is both a language (via movements and interacting) and a way of thinking (via modes). I'm still adjusting to all of those, but it's gotten to the point where I think of a task, attempt it with the shortcuts I know (the "language"), and 2/3 of the time, it just works.
2. Is there speed over previous IDEs and text editors? It's about the same for me, with the added benefit that I'm no longer tied to a system I have to pay for, it's cross-platform, and pretty available in most sports.
For Mac at least, there are things like MacVIM where I believe they let you use your mouse to click around. I did all of my learning from the Laracasts vim series, and I really like his approach of doing what works for you. MacVIM adds shortcuts like command-S to save instead of :w and stuff. If it works for you, cool. I took the approach that I want to learn the base system (plus plugins) because that is a more common cross-platform interface.
From using an IDE, I don't know if I'm saving time by not using the mouse or not, but I know that I can more quickly get places within the code if I know where I'm going. I assume the benefit of not reaching over to use the mouse is helping, but I can't really tell.
For me, there were other reasons, but I don't regret the switch at all. I'm still quite the novice, but I've switched to using it nearly exclusively for projects. (If I just need to quickly open a file from the Mac Finder, I double-click and something non-vim opens. I'm OK with that, I'm no purist.)
The only place it bites you is when you use vim for a while and then go back to something like Code or SublimeText and you're typing vim commands into the screen as characters. Make sure you double-check your work so that you're not pushing ":w"'s up to production. :)
Eh, Sublime's vim emulation is fairly terrible. There are a bunch of common commands missing, and it doesn't integrate well with some of Sublime's features.
For example, if you use tab-completion in insert mode, it records the action as what you actually typed rather than the completed text. So if you press . to repeat it somewhere else, it inserts the gibberish you actually typed. (And Sublime's fuzzy matching is really good, so that gibberish can be pretty bad...)
I often code with my laptop while I ride an exercise bike. Can't use a mouse there. Trackpad is terrible when hands are sweaty. Move too much for home row, so I two-finger type. Vim is great for this.
I've been using it as a plugin for pycharm and sublime text. I still end up using my mouse for larger, more involved editing, but I find it really useful to stay on the keyboard when moving around a file.
Another feature is that it's the easiest editor to configure and extend to be just how you like it. Parsing company specific log files for example, can be done in a few lines of code.
The thing that helped me most with vi(m) was this change of mindset: don't treat Insert as an alternative mode. Instead, threat the append and insert commands as any other command, just ones that happen to (often) take long arguments, and make it a habit to always terminate those arguments with <esc>.
I continue to be baffled that software written 40+ years ago, to deal with constraints and realities that are long long gone keep being used by people on the cutting edge of technology change.
In my opinion, vim's command line usage (while quite nice) isn't the reason why people are so die hard about it. Vim is one of the very few editors out there that provide language based commands, allowing you to chain and build a command in the same way that you'd tell a human how to work. Vim's shortcuts have nouns, adjectives, and verbs. Try implementing something similar in a modern IDE and you'll find that vim's syntax for hotkeys is actually really well designed. That's why you always see vim-modes for modern IDEs - they want the language that it provides, not the command line functionality/ubiquity of vi.
The thing is the "old" software hasn't stood still for 40 years. It's like jazz. Most jazz fans don't spend their time listening to early 1920s jazz but modern forms that evolved from it.
I've been very happy with the IntelliJ, RubyMine, WebStorm family of IDEs.
They have similar UIs to all the other modern software I use, doesn't require a learning curve to start typing, and have tons of features the vi/emacs people don't miss because they don't know they exist.
I understand that it's hard for old timer to learn a new tool. I do not understand why they're still taught to beginner programmers.
What features do you think we're missing from WebStorm?
I've used WebStorm quite a bit in an old job where it's use was mandated by management.
What I found was that lots the headline features didn't work for the hairy old JavaScript codebase and certainly didn't work as well as Tern + ctags.
E.g. navigating to method definitions fell back to a simple search when dealing with react.js modules. As did refactorings such as rename (provided by Tern).
Gulp/webpack/grunt do a better job at workflow tasks IMHO too.
I guess there was the debugger but it's not a patch on Chrome's debugger so why use it?
What Vim, and a lot of other programs, really need is a single plastic-covered card which tells you how to use the program. You can squeeze a summary of calculus on one such card. Is it too much to ask for software?
(I really, really want that for Blender. The Blender hotkey document is 9 pages and years out of date.)
Oh, "for humans"... It was cool when requests came out and it made sense to the audience (Python people familiar with the standard library). But it gets applied to so many things these days that it's just corny. I suppose most people using it intend to convey a folksy, whimsical, self-conscious style. It's supposed to make the content seem approachable.
The folks behind the "Head First!" series seem to understand the appeal of making content approachable. So did the creators of the "For Dummies" series. Hell, Reagan used jelly beans.
It feels dishonest, somehow. Just call it a vim book, or whatever.
I am old enough to know vim pretty well and I guess I do not need the e-book, but I just wanted to congratulate you for the landing page: clear design and better content. I just love the pitch "How do I quit this @#!?"
Which is okay in conversation, but in writing, your pedantic editor or proofreader would probably inform you that it is considered poor style to end the sentence on a preposition. So he's basically trading one error for another.
Who/whom is indeed awkward at first to remember, but the phrase "for whom" tends to sound better on the tongue than some of the others due to its inclusion in the title "For Whom the Bell Tolls," a popular novel (or "popular Metallica song", depending on your age).
Given the rephrasing was done to avoid the question of "should we use 'who' or 'whom' here?", I think it's fair to point out that the new phrasing suffers from the same problem.
Anyone using vim-mode plugins for other IDEs? Most vim critic in the comments seems to be against it as an IDE, while the biggest benefit is obviously the keyboard control. So why not use the combination of both (I installed plugins for Visual Studio and Atom a few days ago and I'm quite happy so far, but it's my first steps in to vim, so maybe I'll find things that won't work later)?
Wow this site doesn't work at all. I clicked on the "download the ebook" and nothing happened. Scrolled down, entered $0 and I get a blank page. Anything above $0, credit card form works fine.
I never really liked C-[, kj is just a finger roll away and it's ingrained in my muscle memory now. I try to avoid shift as much as possible as I get a very cramped finger if I have to use shift too much. I have a lot of custom TeX bindings for this as well (i.e. <Leader>b => {} (braces), <Leader>p => () (paren)). I even rebound 44 to $$ because I don't type 44 that often anyway.
Personally, because it offers me no benefit: [ is on the other hand, so it's the same speed as hitting a single key, and I use Ctrl for many other things; Esc is specialized. I'm also an Emacs (and vim) user (Evil mode, of course).
Your comment comes across as one who has their head stuck in the sand, frankly. Yes — the basics are a bit odd and initially off putting to novice users. I don't think many vim users are promoting vim for its learning curve, we're promoting it for its productivity in the more intricate editing. I still feel a little joy inside any time I use da' or ci( (delete around single quotes — i.e., remove this string, and cut inside parens, i.e., remove the arg list an start ending a replacement). Those commands in particular I find incredibly common, and the arcane shortcuts — while arcane — save me a lot of tedious Shift+Ctrl+arrow,arrow,arrow,arrow… in your more run of the mill editor.
And for the truly complex edits, :normal makes a boring, monotonous task faster … and more fun.
(MSVS has it's own issues: the last time I used Visual Studio, granted, it was ~7 years ago, it lacked ? in its regex syntax, and grouping was with {}, I think. Tell me that editing with a different regex syntax than what your .Net code uses is intuitive? The auto-complete was really good, though. (Though vim comes with out of the box heuristical completion that gets most of the way there.)
"esoteric" and "cryptic"? Have you ever learned vim keybindings? They improve my productivity by a nontrivial percentage. Tens of thousands of other developers have the same opinion.
Unlike Atom and Sublime, vim is far more performant and is available on every machine I SSH into. I'd drop into an IDE (with vim keybindings) for a large Java or C++ project, but vim wins every other time.
You should give learning vim a try at some point if you haven't already. It's a steep learning curve, but it all pays off. Typing vim movements feels like playing a piano.
I used emacs (so I use the emacs key bindings), then I moved onto SublimeText and never looked back. I totally agree that vim/emacs like keybindings can improve productivity. But many editors can easily support this, so you don't have to succumb to these editors like vim/emacs where everything is then complicated when you really just want the keybindings.
P.s here's some Elisp for all the emacks hackers. Very useful, feel free to use (;
I once thought the same thing. Then I started working with in the terminal environment on a regular basis. It forced me to learn vim as an IDE. I'm surprised to say that once I got in a groove with it I find regular text editors painfully slow in comparison. I employ vim bindings to intellij my Web browser and anywhere else possible. I challenge you to watch this video, spend a few days trying it out and report back to this comment https://youtu.be/5r6yzFEXajQ
Not to crap on the author of this but I'd recommend Drew Neil's Practical Vim over this (and pretty much every other Vim book).
https://pragprog.com/book/dnvim/practical-vim