when I first tried exiting vi, many many many years ago, I got yelled at by the system admins because of all the stopped (^Z) processes on the server taking up all the system memory. good times! good times!
Oh boy, this reminds me of Starcraft players having to learn the 'Core' hotkey layout. They learned the game using keys that corresponded to the first letter of the unit ('M' = Marine) until someone figured out that you could just group them all on the left side of the keyboard ('A' =Marine) for faster controls.
Ctrl-[ is mapped to escape by default in vim, which means no annoying rebinding of esc on your os (leaving capslock free to be mapped to ctrl, as G-d intended.)
The whole point of rebinding Caps Lock to Esc is that you have a quick way to escape to normal mode which you do often in vim. C-[ is hell of a convenient combination to press often. And i wonder what on earth do you need to remap Caps lock to Ctrl for? Emacs?
Vim emulation with bindings in favorite IDEs is a really good thing. It's the best of both worlds, you have all the powerful abilities of Vim and the great tools of you IDE. I've been running like that for 2 years and it's great. I also recommend using vimium for chrome and firefox. It has a lot of powerful vim commands and makes your navigation smoother.
There're most of languages have autocompletion in Vim (that means "power" from Latin). I use Vim for R and .netcore development. U must to trying "Vimium C" fork from one chinese man with many extended functions such as dark mode for Vomni, close tabs / cleaning history from Vomnibar, same Vimium navigation in PDF. But in Chrome not read headers of Tabs sleeping by TabSuspender.
@@TehGettinq Or just use a tiling window manager if you aim to have a keyboard driven experience and ditch tmux ( unless you need sessions and other non tiling related stuff )
i think vim is absolutely insane for efficiency after watching, i always found it cumbersome switching windows to go from terminal to vs code. i think i'll actually go through the growing pains of learning the basic commands to navigate through my code.
It's not insane! If we look just at the side of coding apps then IDEs (from jetbrains for example) can give u a pretty good efficiency. Sometimes people learn vim + fast typing then they think that they are superefficient but the same time everything they do is just playing the fucking piano on a keyboard
Command mode also gives you shell access, eg :!ls. Adding the '!' to anything in command mode causes VIM to shell out. I get a lot of mileage from '!' and ctrl-z and fg when going back and forth of VIM and the shell.
@@bepd to do this in vim use :term But there are other options that also work like using a manager like tmux or as somebody said bellow using ctrl-z and fg. Or opening anther tab. Each method is nice in its own way.
I am of the opinion that the editor matter less than what he conveyed at the beginning of this lecture. One thing is to try to write code in programs that have very few features. Another thing is to compare full feature editing tools tuned to the sole purpose of writing code. Yeah, efficient people who uses VIM do it very efficiently... so as efficient people writing in visual studio or their favorite IDE. I didn't buy the argument that at 20 hours will get the same speed and then forward you will see improvement. We see improvements on every tool we have expertise. The one argument in favor of vim, in my opinion, is to be able to efficiently work when you cannot control the environment. If you write a lot of code remotely on the cloud, for example, or if you have to access someone else's computer but they don't have the software you use. Otherwise, you can get the same level of optimization with any other editor. Whenever I see someone saying that it is inherently more efficient and practical to use vi, I think it is just confirmation bias .
You will definitely edit text way faster in vim/nvim than in any other editor/ide. Its not even close to being comparable. Does it matter? probably not really.
@@TehGettinq I don't think it is an easy statement to accept. First, people can get very proficient with their set of tools. Blind people using assistive aids can navigate through their phones as fast as non blind people for example. So it could be, at least theoretically, that very proficient vim users do as well as an equivalent non vim user that are also experienced users of their set of tools. Hard to know for sure, but also hard to deny it as well. It is hard even to test this. Yeah, one can show a workflow where vim is incredibly faster than any other method... But nitpicking a couple or dozen of cases while ignoring the entire universe of cases the industry demands does not prove anything. Another way to think about it is that the market tends towards efficiency of resources. If vim was really that much better at delivering productivity, the market would tend to make non vim editors obsolete (no company uses punch cards anymore). This does not happen. What we see is a spectrum of tools used by a spectrum of users. This makes me believe two things: First, many of these tools could each one be better at specific set of tasks, but none being better overall, and second, the cost of learning and getting experience with a specific tool might damage productivity as a whole, which makes the industry tends towards an equilibrium between users that use vim and users that don't. This would explain the distribution and there would be no reason to argue in favor of one or another like that. In either case there is no indication of superiority.
@@TehGettinqYou may be able to edit text faster, but can you do full-scale refactoring with IDE scan for usages, instant creation of getter/setter methods, step-debugging with live evaluation of arbitrary expressions at any line you want, instant scroll of all usages of a method/variable/class, alongside many powerful features of a commercial grade IDE like Intellij IDEA? Maybe you could configure all of those things, but surely not in 20 hours. More like 200 hours of trial and error and frustration probably, and still not get the desired effect. Not to mention you can do pretty much everything in IntelliJ IDEA with keyboard shortcuts. I pretty much never have to touch my mouse when using IntelliJ IDEA.
At the bottom of the ~/.vimrc file you can find the lines that start with inoremap. Simply remove these lines (or mark them as comments) and you should be good to go! In normal mode however, the blocking of the arrow keys still persists.
@@БарометрАтмосферный Vim is by far not the most minimalist text editor; Vim is a very big one. Smaller text editors are, for example, ed(1), ex(1) and sam(1). Vim has stuff like many built-in features and plugins, including tabs&splits, a built-in terminal emulator, syntax highlighting, GDB integration, sessions, an own scripting language, etc.
I use Vim for everything except Java and Scala. For those, nothing beats Jetbrains Intellij IDEA. It also comes with Vim bindings, though I find them not that productive.
Here is the official repo github.com/vim/vim You can check the documentation section which states: "The Vim tutor is a one hour training course for beginners. Often it can be started as vimtutor. See :help tutor for more information." This should get new users started.
Yes, we agree with Slobodan, the goal of this lecture is not to supersede vimtutor (it's actually our exercise 1), it's more about communicating the philosophy of vim and showing off some of its features.
@@MissingSemester It's always nicer and more inspiring to see someone actually use it and demonstrate it than to read a book or jump straight in to the deep end. So this lecture was refreshing for me (I already knew vim but forgot some things) and I can see this being very useful for those who have never even tried to use it, not even knew about vimtutor.. because lets face it.. majority of new Linux users dont even "man" or --help anything. They like to see others do it, and/or be told what to do.
@@anthonytonev1357 tbh all the good programmers ive seen use vim or emacs. Like if youre on windows doing java i understand you think vim is retarded but that would imply you also dont know shit so its kind of contradictory.
Speaking for my personal experience regarding your second question. Before I started learning vim, I used JetBrain's intelliJ when I was learning Java. I am a rather quick at typing, so inefficiency wasn't really an issue. At some point I started trying to learn vim. I don't remember what got me to learn it at this point, but I used the vim emulator in intelliJ. It was a struggle. I was comparably slow, misused keys from being used to the standard typing key binding, using the mouse and such. It took me a couple weeks of on and off using vim before I actually started to use it majority of the time. Later full time :) Now I've been using vim for over two years, the speed at which I am able to edit and traverse files is way faster than in a bare editor. Visual Studio and intelliJ are great editors, but are heavy. And when you're working as a backend programmer you very often have to ssh into servers where all you have is your command line interface, often with only vim/nano installed (sometimes even the old vi is the only editor available). I won't say that this editor or that is better, but to me vim feels like a sharp, efficient tool in a programmer's toolbox. Then comes the customization, the plugins, the freedom of tailoring your editing environment to your needs. It's a rabbit hole and I love it :) I feel at home using vim (or neovim, actually, but it's the same thing except maintained better)
Depends on what your building... Expert programmers sometimes dont need a full IDE and will use VIM and then just GCC or G++ (or whatever compiler you prefer depending on the language you write in) the files.. Some programmers need the bloated IDE because their company makes it mandatory because theyre working on a big project that has tens perhaps hundreds of coders working on who may need to use your code to build their code so its more streamlined.. But if you're a one man wrecking crew coder building a backend, driver or even a game.. you can use vim and get things done just as quick.. theres autospell and syntax coloring so they can work pretty damn effeciently in vim.
@@brenchille As a noob I am, I prefer nano. This is what really works for quick edits. Vim could be the most powerful editor ever, but its UX and learning curve still frightens me off.
Imagine studying something useful that's also difficult enough that you have to watch a lecture in order to be productive in it as a career. That couldn't possibly be a good life choice
@@bed7496 the dot . normal command repeats the last change. The last change is anything you do to change text in the current buffer. Eg, Inside vim on a new line: ^[iChange^M^[.... ^M - Enter ^[ - Escape :help .
In the early 90s, I went to Northeastern U., just across the river from MIT. I took a similar class like this one. The lecturer was also a TA, however, I was taught to use Emacs and brainwashed to think that Emacs was the only thing (and Lisp) a programmer would need. I was too young to know about the Cold War between Vi and Emacs churches.
And most of them are certainly on a Mac or Windows using floating windows manager while learning how to get fast with the keyboard using vim, total nonsense, or how to do a marathon while eating McDonald's
Even after I jump-shipped to Emacs, I still use the vi-emulation (a.k.a. evil-mode) because tbh, vi-style bindings has just become an intuition for editing code and text.
dwi and cw have another difference: cw is a single change, and repeating it with dot (.) will repeat the deletion and the inserted change. While with dwi, the repetition will only repeat the inserted text.
@@Adolf1Extra No. dwi is a delete command, not an insert command. i in this case follows a text object w, meaning word. Thus, this i means inner, not insert
Change in character is one command I've been wanting for a while! So happy this exists. I've been learning Vim on and off for the last week and that was one I didn't know about. I'm glad I watched this.
Instead of rebinding caps lock, you can also use C-[ instead of ESC. C-c works, too... sort of. There are some caveats with C-c and I wouldn't recommend using it. It breaks some plugins and might require some additional configuration to behave more similar to ESC.
if only my professor taught me this thing, i would have gotten to cs much earlier. my professor taught us html using .txt file , just changing the ext. name
My god, until now, this is the holy video let me run speed at x1.0, even slower. Respect! BTW, anyone know how to record key stroke on video above on Linux (except Keymon & screenkey) ? Thank you very much.
@@KieranDevvs No mouse ( less joint aches ) and portability are the two main reasons I use vim and to be practical, MS Notepad? Really? Okay, I don't use notepad because it lacks FEW of the features or facilities that Vim provide me.
@@almasfizashaikh6159 ya :q is the standard methods of exiting vim, there are two other methods which I know are :wq and :q! or :qa!. :wq saves the file and quits the Vim window (:wa lets u save and keep working), :q! and :qa! are not recommended though :)
@@your_name96 There's also :x, which does the same as :wq. (Well... :x only saves the file if it was actually changed, while :wq does a write even if it is unchanged. This will only be relevant in very niche cases, though)
should I force myself to go through the pain of getting the muscle memory of all these commands or tailoring it to my needs or just be left curve vs code user?
gg - move the cursor all the way to top G - move the cursor all the way to bottom L - move the cursor to last line of the screen M - move the cursor to middle line of the screen H - move the cursor to top of the screen : - move to specified line ^e - scroll up one line ^y - scroll down one line ^u - scroll up ^d - scroll down dd - deletes a line dw - deletes a word x - deletes a char p - paste u - undo 0 - beginning of line $ - end of line ^ - first char of line g_ - last char of line w - moves the cursor forward 1 word b - moves the cursor backward 1 word i - insert mode ESC - Normal mode : - command mode :q - quit a file :q! - force quit :w - writes the changes :wq - write and quit :w [filename] - write to specified file
Even if you decide not to use VIM, learning the navigation keybindings are still pretty useful. I suppose more accurately I could say ex-normal mode is what I'm talking about here. Off the top of my head the less, man pages, git log output programs support VIM navigation bindings including search, eg. '/' or '?'. I'm sure I'm leaving out dozens of programs. Pretty much most Linux tui programs support VIM style navigation.
vim have normal mode not because "this is whole new world and programing language", but just more pragmatic reason. There is not enough hotkeys(reasonably ergonomic hotkeys) if you keep letters to work as text input. That is why you need to have modes.
Alright, i still don’t understand why this will make me more efficient editing code, compared to, say, sublime.... or compared to using a mouse..... i get it if you are in a Linux system and vim is the only editor available... but if you are using a Mac or windows machine, why vim?
In my experience, using vim with touch typing would increase your efficiency by a lot. It takes time to get used to it though. But as you spend more time programming, you get kind of annoyed when you need to reach for your mouse or the arrow keys to select something a few lines above, because with vim you can just switch to visual mode and use the hjkl keys to navigate which are keys that are already near your fingers.
Tbh, the differential isn't worth it. Vi users tout the "code as fast as you think" bit as a selling point, but the truth is that most programmers need to learn to think and type slower, not faster. The real value of Vi (or Emacs or Nano) is that virtually every standard server will have it. Pushing mouse inputs through an ssh tunnel to the other side of the world is inefficient at best, and the weight of a graphical interface makes it non-ideal. And even that is less and less of an issue, because editing a file on a server probably suggests you're doing something wrong, and as the industry's standards have improved, the need is just rarer and rarer. I personally use vim because that used to be a real concern (a company I used to work at preferred us all work off development environments located on company servers, so you'd have to ssh in to do anything to begin with), and now it's just a habit. The real takeaway that I feel this class didn't advocate strongly enough for is this: pick your tool, and learn it well. If it's vim, great. If it's vscode or intellij, great. Learn its quirks, how it thinks, why it makes what choices it does, how to get it to do all sorts of stuff. And also learn its limitations. Vim will always be terrible with a visual programming language, for example. But the point is that, if a tool is in your toolbox, be good at the tool. But pick one. It doesn't have to be the best. It just has to be _your_ best.
@@Duiker36 Most Linux distros I've encountered don't have emacs installed by default. I could be wrong, but I seem to recall needing to install it whenever I've wanted to use it.
As you learn more, there are things that are far more efficient in vim, Sorting code, putting variable s into columns, removing duplicate lines, recording macros and say a couple keystrokes to repeat that macro a thousand times. Plus most text editors don't have a dictionary built in, the ability to add a thesaurus, there are allot of things that other editors just don't do well, or at all. But it depends on how somebody uses it, if they use it like a regular text editor and don't learn the features, there probably won't be much benefit.
vim is that text editor you still learn new stuff over the years and improve, even organically by deducting stuff. Macros, the dot command, :!% command and finally :norm are the ones that got me convinced to use it for everything.
