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 ;)
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