Vim for Humans
vimebook.com
vimebook.com
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).
The defaults are just bad, I recommend using vim-sensible or doing your own lean and mean vim config.
For someone who is new to Vim, they wouldn't know if the controls are bad, or tough to learn e.g. using jkl; instead of arrow keys.
By default, vim doesn't enable filetype detection or syntax highlighting, so even though it can easily recognize a source file's language, it doesn't.
(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.)
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.
Where are you going with that?
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.
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.
http://www.catb.org/esr/writings/taoup/html/ch20s03.html
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
Using desktop environments. If I click on a text file in KDE, it opens in kate. Same with every other linux desktop I've used and same one mac.
You're yet to say a single thing that doesn't apply equally on windows and unix.
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?
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.
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.
http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...
As someone who authored XCB, you should be no stranger to separation of policy from mechanism.
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 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.
Same for config files.
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'm a huge ijkl fan, because I learned wasd long before I learned vim.
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 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.
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.
(We've started deploying something like vim-sensible, though I didn't know about vim-sensible, so I might start deploying that.)
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).
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.
One other link I haven't seen mentioned here is the user-manual[0] or typing (:h user-manual), and of course typing `vimtutor` at the shell...
For Vim and much else, I've found it worth reacquainting with "as is," after years and decades of customization.
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.
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.
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:
http://blog.bugreplay.com/post/149712686514/how-i-learned-to...
This is understandable. Coming from Emacs, I need an equivalent of projectile to stay productive while learning.
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.
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.
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.
Well, anyways maybe NeoVim is good after all.
https://www.youtube.com/watch?v=HKF41ivkBb0
it's also under active development so if that's your thing check it out.
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.
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).
Creating a user specific script in vim is an order of magnitude simpler than atom.
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.
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.
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 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).
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.
This article was actually eye-opening for me: https://yanpritzker.com/learn-to-speak-vim-verbs-nouns-and-m...
Maybe it'll help you too.
:wq
git checkout $(lw 5kyiW)
http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-shee...
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.
I remapped the leader key to space, and created a bunch of sensible mappings: all my Markdown mappings are under <space>m and so on.
I left most of the normal mode movements at their defaults, though.
It would be cool if someone could do a Spacevim vimrc or plugin.
Here's how to think of Vim that will make sense.
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.
Because yes, Vim ultimately will be faster.
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.
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.
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 still use editors like atom for web development where I go through frequent iteration cycles and make heavy use of the clipboard.
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.
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.
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.
I second the suggestion of using vimtutor to get started (uninstalling other editors helps too!).
i was just one of the ones stupid enough to waste two weeks of productivity to learn a new tool lol
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
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 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.
[1]: https://ianchanning.wordpress.com/2012/04/07/vi-commands-for-the-windows-user/
[2]: https://github.com/neilpa/cmd-colors-solarized/
[3]: https://dl.dropboxusercontent.com/u/7765571/images/screenshots/2016-10-17%2020_32_05-Make%20me%20a%20sandwich%20-%20vim%20%20DNA.hs.pngCan I make an alias for vim or emacs to keep me in edit mode at all times? That's one of the worst things about the editor.
The other "Worst" thing in the editor for me is that it doesn't show the common shortcuts at the bottom like nano does.
Is there a way to do this? Is there a plugin that observes all of the shortcuts you use and lists the most common ones at the bottom?
http://supportweb.cs.bham.ac.uk/documentation/tutorials/docs...
Personally I would just run vimtutor in the terminal, watch vimcasts.org and then read the PragProg book.
it would be cool to be able to open
files without having to do File -> Open
using the menu bar
> 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
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.
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.
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?
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.
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.
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
- 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
- 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 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.
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.
Similarly, if I want to change them or delete them the y becomes a c or d.
Try triple click ;)
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.
Neat, I didn't know that - thanks for the tip!
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.
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. :)
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...)
Well that's how I now feel when someone else is editing a file without Vim.
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)
<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.
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.
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.
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.
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.
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.
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.
d delete
c change
t 'til
f find
a after
i insert
u undo
o open a new line
p paste or put
n next occurance
b back a word
y yank (copy)
v visual
ect.
coupled with an object that are less friendly to learn but there aren't that many of them
w word
e end of word
( sentence
{ paragraph
text blocks are directly what you want to change
" double quotes
' single quotes
( parenthesis
{ curly brackets
t tag
ci( change inside the (
da" deletes around the double quote, etc.
it's easy to compose sentences for editing text.
this person does more to explain why: http://stackoverflow.com/questions/1218390/what-is-your-most...
Try running vim on PDP-11. I dare ya.
What would you suggest people use instead?
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.
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?
(I really, really want that for Blender. The Blender hotkey document is 9 pages and years out of date.)
https://duckduckgo.com/?q=vim+cheatsheet&t=ffab&ia=cheatshee...
There are similar pages for various programs, including blender it seems: https://duckduckgo.com/?q=blender+cheatsheet&t=ffab&ia=cheat...
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.
Sidenote: The navbar & images break on smaller screens.
My e-mail is sorhed at gmail
If the author is reading this, proper English would be "For whom?" The intro says he's not a native speaker, so it's a common mistake. Easily fixed.
Who is this book for?
You can tell because the answer is 'her/him', not 'he/she'.
If you can understand it, it's not incorrect. You might not like the style, but that doesn't make it wrong.
acn yuo stunderand htis? i no oyu cna so acocrding ot yuo its nto rwong. oaky.
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).
By some, sure, but not really legitimately. See https://en.wikipedia.org/wiki/Preposition_stranding#Opinions..., and of course plenty on Language Log including http://languagelog.ldc.upenn.edu/nll/?p=2752
:imap kj <Esc>
I also bind caps lock to ctrl (setxkbmap -option ctrl:nocaps on a GNU/Linux system), which makes this all the more natural.
setxkbmap -option caps:escape
Of course you could map caps lock to be both ctrl and escape at the same time but C-[ is almost as good.
I didn't know about C-[ though, i've been using C-c which is also an <Esc> equivalent by default. On MacOS anyway.
C-[ is though, and because it's part of the terminal it'll work in other Vi like places like the command line (set -o vi) and ncurses.
Vim mode all the things.
cool
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.)