[HN Gopher] Vim Reference Guide
___________________________________________________________________
Vim Reference Guide
Hello! "Vim Reference Guide" is intended as a concise learning
resource for beginner to intermediate level Vim users. I hope this
guide would make it much easier for you to discover Vim features
and learning resources than my own blundering experience. To
celebrate the release, ebook version is free to download till
31-Mar-2022: *
https://learnbyexample.gumroad.com/l/vim_reference_guide *
https://leanpub.com/vim_reference_guide Some of my other ebooks
and bundles are on sale and I'm currently creating short 1-3 minute
videos to highlight Vim features. You can find these details in the
above links. Visit https://github.com/learnbyexample/vim_reference
for markdown source and other details related to the book. Hope
you find these resources useful. Let me know your feedback. Happy
learning :)
Author : asicsp
Score : 169 points
Date : 2022-03-15 11:56 UTC (11 hours ago)
(HTM) web link (learnbyexample.github.io)
(TXT) w3m dump (learnbyexample.github.io)
| asciimov wrote:
| I always feel that how to exit and quit vim should be at the very
| top of the first page. With a quick explanation for the various
| ways to do it. ZQ - in normal mode, quits (notice
| no colon and capital) ZZ - in normal mode, saves only
| if file was modified and quits :x - same as ZZ
| :w - write the file :wq - writes the file regardless
| of changes and quits :q - quit, if no changes
| :q! - quit, regardless of changes :w !sudo tee % - For
| when you need to save a file you don't have permission to and you
| forgot to start vim with sudo.
|
| Edit: Also note the difference between 'ZZ' and ':wq'. While 'ZZ'
| doesn't make any changes to the file system if the file hasn't
| been modified, ':wq' will at minimum change the date of last
| modification to the time that save was ran even if the file was
| not modified.
| JNRowe wrote:
| Might also want to note :cq[uit] to quit with an error code.
| This can often be useful when you're using vim as your $EDITOR
| and wish to tell the calling process that you want to abort.
| asciimov wrote:
| Good call, I think I've only used :cq once(?).
| JNRowe wrote:
| Oops, I probably could've offered examples. So, when
| writing a mail I can choose to simply give up instead of
| dropping me in to a dialog for "save draft/quit?", or to
| drop out of an edit session in `git add --interactive`,
| etc. The reason it can be useful in these specific
| instances is that you don't need to unwind your changes if
| you've run filters to modify the text for example.
| sundarurfriend wrote:
| > :w - write the file
|
| > :wq - writes the file regardless of changes and quits
|
| The first one is also "write the file regardless of changes",
| to be clear. The command version of "saves only if file was
| modified" is :up (for update). I have that mapped to a normal
| mode key and rarely ever use `:w`.
| asciimov wrote:
| Just learned about update, after 18 years of vimming, thanks!
| LamJH wrote:
| I learnt regular expression by reading your books, thank you for
| the great work.
| syngrog66 wrote:
| pro-tip: the "Hello World" for any vi/vim reference is to start
| by showing the user how to exit it. safely, quickly, ideally with
| no loss of edit state
|
| please, we beg you, for the love of humanity. there have been
| anecdotal tales of folks trapped inside vi sessions for weeks,
| months, even years, ultimately passing from lack of water or food
| doix wrote:
| Hi, great work releasing this! Trying to explain vim concisely is
| always an interesting challenge and I had a great time reading
| your attempt in this book. I always find it really interesting on
| how people try to group certain vim functions in a way that makes
| sense to people that don't use vim.
|
| Whenever I try to explain vim to other people, I always start
| super abstract, i.e 'vim grammar is all (count)? verb then
| object. Learn actions and then the movements to apply the action
| where you want'. I think you cover that idea pretty well in your
| 'Vim philosophy and features' section whilst not making it overly
| abstract and keeping it relatable.
|
| Some things I noticed, you mention registers in the insert mode
| section before explaining what they are. It seemed odd to me that
| you used the word before explaining what it meant, but maybe it
| is unavoidable?
|
| I also noticed you completely left out folds (z, :help fold).
| Personally, I aggressively fold code I'm not working on so I
| think they are super important :D. There was a plugin posted
| recently thats a cool alternative to folding though (similar to
| emacs narrow) [0] [1].
|
| [0] https://github.com/hoschi/yode-nvim
|
| [1] https://news.ycombinator.com/item?id=30305011
| asicsp wrote:
| Thanks for your feedback. And your point about 'Vim philosophy
| and features' section is interesting. I find it difficult to
| explain abstractly and I wondered if I should copy-paste some
| sections from the famous "you don't grok vi" answer
| (https://stackoverflow.com/a/1220118).
|
| > _Some things I noticed, you mention registers in the insert
| mode section before explaining what they are. It seemed odd to
| me that you used the word before explaining what it meant, but
| maybe it is unavoidable?_
|
| Yeah, my chapter structuring ended up in many cases like that.
| For example, I mention how to modify behavior of left/right
| arrow keys to move across lines using a setting. But, Command-
| line mode chapter comes later and use of vimrc comes even
| later. For cases like registers in Insert mode chapter, I
| linked to the Normal mode section after the bullet points (may
| be I could move it to the start of section).
|
| > _I also noticed you completely left out folds_
|
| I knew that there's a fold feature but haven't used them. I
| think I cover only about three commands with `z` in Normal mode
| chapter. I don't use multiple buffers in same window, tags,
| third-party packages, etc - so details on them are light too
| (or entirely missing).
| doix wrote:
| Oh yeah, I just realized you completely left that stuff out.
| That's one of my favorite parts of vim and what I find
| lacking in 'vim mode' plugins. They get the hotkeys right,
| but they lack the abstractions of tabs/buffers/windows. What
| most editors call 'tabs' are windows in vim, and they lack
| the concept of a vim tab. I use them all the time when I'm
| doing refactoring work. Being able to organize 'views' in a
| way that makes sense, then switch between them rapidly is so
| awesome. You're refactoring some code across 3 files (all
| open in splits), then you want to look up some other part of
| the code base for reference. :tabe browse around, read
| whatever with 100% of the screen devoted to what you're
| trying to read, then gT and you're back on your old view with
| 3 buffers open. I have to constantly build up and then
| destroy these views in other editors. Or just accept that
| half my screen is cluttered up with irrelevant stuff.
|
| Also the fact that everything in vim is a buffer inside a
| window means that everything is super consistent! You can
| switch focus between your plugin windows and your files with
| the same hotkeys! And unless the plugin writer intentionally
| changed stuff, the plugin buffer works just like a normal
| buffer, so all the hotkeys you learned before still apply.
| It's what I really miss in IntelliJ IDE's. I can see all the
| different panels, but I cannot switch focus to them without
| memorizing panel-specific hotkeys! I can see the bloody panel
| is left of my current focus, let me switch focus by just
| pressing ctrl+h instead of alt+shift+3.
|
| Anyway, vim is very vast and trying to explain everything is
| a daunting task. I think you've made a good attempt :).
| cassepipe wrote:
| When I was first introduced to Vim I thought : Modal editing is a
| great idea! I also thought why the hell do I have to hit Esc to
| get into normal mode!? You couldn't make a key further for the
| home row. So I refused to use it for a month until I stumbled on
| a Reddit post on how to swap the Esc key and Caps Lock :
| "setxkbmap -option caps:swapescape" on Linux. Somewhere in the
| settings for MacOs. For Linux you don't have to swap, there are
| other clever options.
|
| Turns out that Esc on old "Unix" keyboards use to sit where Caps
| Lock is on modern keyboards
|
| Another popular option is to have "jk" switch to normal mode as
| you are unlikely to need to insert that combination of letters.
|
| How almost all introductions to Vim do not mention that
| historical fact and the fix for it, is beyond me.
| chockchocschoir wrote:
| Swapping caps lock for escape is something that I first started
| going because of Vim, but now can't live without, in every
| context! I even started using it on other operating systems,
| even if I don't use Vim on them (mostly Windows and macOS),
| because it's so useful.
|
| Only trouble are in some games on Windows where the developers
| seems to have hardcoded the game to react to the actual Escape
| key instead of the key in the operating system, so pressing
| Caps Lock has no effect, and pressing escape does show the
| pause menu but also turns on caps lock (as I have it switched).
|
| Other than that, life is much better with them swapped.
| barbs wrote:
| Same here! I primarily use linux and MacOS and have bound
| caps lock to escape for both of them. I rarely miss caps
| lock, it's better to keep your voice down online anyway ;)
| sundarurfriend wrote:
| I just have two escape keys - the actual key and Caps Lock.
| Do you find that you actually use Caps Lock for anything?
| scns wrote:
| I do, for names in CONSTANT_CASE. But i use the Neo layout,
| where you press left + right Shift for Caps lock
| functionality. The Caps lock key itself is the modifier to
| reach layer 3.
| chockchocschoir wrote:
| On Linux, not really. Sometimes I disconnect my keyboard
| and reconnect it again, so the swapping gets restored, and
| I accidentally hit Caps Lock AND EVERYTHING IS BIG NOW.
| THEN I RUN THE SWAP COMMAND AND I'M NOW STUCK IN CAPS LOCK
| MODE unless I could just hit Escape again, which if I
| didn't swap, I couldn't.
|
| Jokes aside, it's mostly on Windows I have use for caps
| lock as some games I play use that key for things, so it's
| handy to have it swapped instead.
| Finnucane wrote:
| But I've already swapped the caps lock for the ctrl key!
| teeray wrote:
| Using Karabiner Elements, you can have tap for escape, hold
| for control. After about a decade of experimenting, I've
| basically decided that that is how the Caps Lock key should
| actually function.
|
| The real escape key is the one that should be Caps Lock
| sodapopcan wrote:
| I do this and it's really great. I don't understand how
| people live with hitting ctrl-c in the default layout of a
| mac keyboard. It's so uncomfortable.
| cturtle wrote:
| Then do ctrl+[ which sends the esc code :)
| auto wrote:
| I had the same issue, and I've found that most people haven't
| discovered that ctrl+[ is the same as hitting the escape key,
| and doesn't require any custom config.
| peakaboo wrote:
| I use Ctrl-c instead of esc, works really nice for me. I prefer
| it to jk actually. But that's the thing, choice. That's the
| best thing about our tools and operating systems. Respect for
| the user choice.
| cassepipe wrote:
| I am all for choice. But the default is just plain bad and
| introductions generally don't even mention Ctrl+c
| dwmbt wrote:
| i think that's what first turns people off from vim. the
| defaults are (subjectively) terrible from an ease-of-use
| perspective. usability wise, nothing beats it. maybe emacs
| competes, but i've never given it a go. i think most
| introductions would do well with showing people how to
| change their configurations first. that's why i use neovim
| anyway.
|
| i took a unix course my third semester at uni and we had an
| entire 2 weeks dedicated to vim and how to feel more
| comfortable in our environments. we were only allowed to
| ssh into our development environments and the professor
| noted he's had a lot of success after ensuring everyone
| felt a-okay at the command line. at the end, we had an
| extra credit assignment where we got to show off our
| configs and present to the class why we made the choices we
| made. some kid even got me to start using some cool plugins
| (goyo, if i remember correctly), he introduced me to
| neovim!
| dwmbt wrote:
| crtl-m for me! i like to map my keys with the keywords i have
| in my head (control + _M_ ode). i really like how you put it
| in that last sentence. though i main my macbook for
| development purposes, my daily driver is a linux machine. i
| never really knew why i liked it other than i like to fuck
| around with different distributions... now that i see it in
| words, i like that the OS respects my choices. if i want to
| change something, i can. it's not impossible on MacOS, it's
| just sort of disrespectful how difficult it is to customize
| your experience!
| gnubison wrote:
| For others reading this, binding ^M and Ret separately will
| only work in a GUI, since they send vim the same bytes in a
| terminal.
| opan wrote:
| I always found this advice annoying (and I actually do see it
| in many vim introductions) and didn't find it particularly bad
| to reach for escape, but I have mostly used 60% keyboards for
| many years now, so esc is one row lower than normal (where the
| ~ key is on a fullsize).
|
| Asking people to remap keys feels pretty major, but also there
| are _many_ things people tell you to replace capslock with. I
| personally think making it a compose key is a better choice.
| jzer0cool wrote:
| Never reached being a vim power user. Somehow I always end back
| up to an IDE especially when it involves a bigger project. Could
| someone share some power user examples when only using vim it
| really shines for programming?
| drekipus wrote:
| I use "recorded on the fly" macros all the time. But other than
| that, I use vim to avoid using an IDE as much as possible. I
| keep in the terminal, have all my tools available, don't have
| to click around or wait for load times, etc. Vim opens
| instantly and I can navigate to where I need to go instantly.
|
| For instance, just yesterday, I had a test failed that was
| comparing two (big) classes of objects, and the test suite
| spits them out as single long lines as a diff.
|
| But looking at long lines are super hard to read, so I can just
| do something once (ie: take a vertical chunk of text between
| zero and the next comma, and append it to end of file) then run
| that macro 70 times, and suddenly that long line I had to
| scroll through is all divvied up and I can easily spot where
| the issue is.
|
| All of this is a bit simpler (believe me!) Compared to trying
| to remember where a certain menu item or action is. I'd
| probably have to pull up excel if I didn't have vim.
|
| But you've heard this all before
| agentwiggles wrote:
| I like Vim's editing model. Vim itself is a truly awesome piece
| of software. BUT - it doesn't have IDE style features, which I
| have come to rely on to do my job effectively, built in.
|
| Luckily for me, Vim's editing model exists in the IDEs I use
| via Vim 'emulation' plugins. In Jetbrains IDEs and in VSCode,
| the emulation is quite good. In the incredibly rare instance
| where I need a macro or some similar 'power user' Vim feature,
| I just pop that file open in Vim.
|
| For me this approach strikes the best balance. I get to use the
| powerful modal editing that I've come to enjoy, while also
| getting to take advantage of the many powerful features of
| IDEs.
| scns wrote:
| IdeaVim by JetBrains does macros. Slower than Vim but still.
| thisisauserid wrote:
| I can't be the only one to use :x instead of :wq but I never see
| it in tutorials. It's 50% fewer keys!
| qiskit wrote:
| ZZ also does the trick, but I always do :wq out of habit. After
| all, you only write and quit once per file.
| opan wrote:
| ZZ and ZQ are both very nice.
|
| On the note of saving/quitting and things not being mentioned
| enough, I only recently learned about :up to only save the
| file if there were actually changes (probably short for
| "update). Saves some time, especially with remote files, if
| you're one to save a lot and not remember if you saved
| recently already. I think this is closer to how emacs saving
| works by default. I bind space-f-s to save files, and tend to
| use that more than :w or similar, so in my case I just
| updated what that keybind did.
| mrpotato wrote:
| Neat stuff! Nowadays, I mostly use Cheatsheet[1] to quickly look
| up things I want to do, but resources like this are always nice
| for learning new stuff you didn't know about.
|
| One piece of feedback is that I would include "+p and "+yy in the
| copy and paste section. I feel like that's the first place where
| people will go to look for "How to copy and paste using
| clipboard".
|
| [1] https://github.com/sudormrfbin/cheatsheet.nvim
| asicsp wrote:
| Thanks.
|
| And that's a good feedback, I'll add something to that effect
| in the next version.
|
| The interactive cheatsheet looks so cool! Gotta try it out.
| Could be extended to programming languages too.
| gigatexal wrote:
| This is a fine resource. For those who love vim already but want
| to really understand it this was shared by my team internally:
| https://github.com/mhinz/vim-galore
| [deleted]
| johncoltrane wrote:
| Another predator preying on newbies.
|
| Don't waste your money on this. Doing $ vimtutor and then going
| through the user manual is all it takes to learn Vim. Easy, free,
| and built-in.
| sundarurfriend wrote:
| They mention vimtutor right on the purchase page, and in the
| book too.
|
| And they provide a link [1] to free Vim resources available
| online, on a page that the author maintains themselves.
|
| This is the opposite of what someone "preying on newbies" would
| do.
|
| [1] https://learnbyexample.github.io/curated_resources/vim.html
| tombert wrote:
| I don't think that this is predatory; even if they're charging
| for this, it's useful to get different perspectives on
| teaching. We're all a bit different, sometimes `vimtutor` isn't
| going to stick.
|
| I mean, taking this logic to its extreme, should universities
| by completely abolished, since most of the information
| available in universities is also available online for free?
| johncoltrane wrote:
| > I mean, taking this logic to its extreme, should
| universities by completely abolished, since most of the
| information available in universities is also available
| online for free?
|
| That would be a different logic.
| tombert wrote:
| How though? All this person is offering is a different
| tutorial for Vim, and they might eventually charge money
| for it. Yes, the information is available for free via
| Vimtutor (or a million other online tutorials), but that
| doesn't make a paid tutorial _predatory_ , any more than
| any other paid information tutorial.
| johncoltrane wrote:
| It's not a different tutorial. It's a gigantic, messy,
| incomplete reference card. And yes, it is predatory, just
| like every other ebook/app/whatever based on the
| misconception that Vim is hard to learn.
| tombert wrote:
| I've been using Vim as my full time editor for a decade
| (well Neovim for the last five years), so believe me when
| I say this: Vim _is_ hard to learn. It 's not a
| misconception. Modal editing never really took off, so
| people's exposure to text editing prior to learning Vim
| is generally something like MSOffice, which is not modal.
|
| Maybe you're some hypergenius who picked up Vim in an
| afternoon, but I know several people who I recommended
| "just go through Vimtutor" and it didn't stick for them.
| johncoltrane wrote:
| 12 years, here, 10 of them spent debunking such nonsense
| and reverting all the silly misconceptions people get
| from tweets/videos/posts/etc. Vim is _not_ hard to learn.
| It's more than a misconception, at this point, it's a
| myth. The learning material is free, easy to follow, and
| goes very progressively from nothing to advanced without
| even assuming computer proficiency. The only requirements
| are a) Vim, b) high school level ESL, c) time.
|
| > Modal editing never really took off, so people's
| exposure to text editing prior to learning Vim is
| generally something like MSOffice, which is not modal.
|
| Well, modal editing is just some $NEW_THING you must
| learn to do $ACTIVITY efficiently. Just like a new
| framework or ice skating. Not having been exposed to it
| prior to your first time is not a handicap because no one
| has. Every budding vimmer is literally equal before modal
| editing.
|
| > Maybe you're some hypergenius who picked up Vim in an
| afternoon
|
| It took me 4 months to know enough of Vim and be
| comfortable enough to ditch my previous editor for good.
|
| > but I know several people who I recommended "just go
| through Vimtutor" and it didn't stick for them.
|
| Well, that's a dumb advice so no surprise, here: you
| rigged them for failure and they failed. vimtutor only
| covers the basics needed for adding a line to /etc/hosts
| or write a commit message so no wonder why they bailed
| out if they believed they were going to be wizards after
| a 30 minutes tutorial. The real learning starts at :help
| user-manual.
|
| Besides, giving up after vimtutor is perfectly OK. Vim is
| just one editor among many and it is not for everyone.
|
| Learning Vim is _not_ hard. What _is_ hard is using it
| efficiently without learning it, which makes people take
| all kinds of silly shortcuts and spread all kinds of
| silly ideas.
| memetomancer wrote:
| you have a very weird mix of arrogance and blinders going
| on here. looking back through the thread, your one
| consistent argument is people are being 'duped' thinking
| they'll be 'wizards' by all these earnest, helpful
| tutorials... and that vim is __not__ hard to learn.
|
| It's simply not the case. Maybe it was the case for you.
| Maybe you purchased a vim book and didn't become this
| mythical hacker wizard. maybe vim seems absurdly simple
| to you because you are a genius. I don't know!
|
| But I do know this - other people have different
| contexts, different knowledge, different experiences than
| you do. When you stomp around angrily and arrogantly
| denouncing a perfectly innocent thing like a vim
| tutorial, and show zero indication that you understand
| that other people find things valuable when you cannot
| see that value... it just makes you look like a fool.
|
| I'd put my money on the notion that very few, if any
| readers of HN are going to be impressed by your furious
| denouncement here - rather they are only going to see a
| weak fool shaking his tiny fists at a perceived slight
| for no special reason. Maybe they'll chuckle. Put me down
| for $20 on that action.
| tombert wrote:
| > It took me 4 months to know enough of Vim and be
| comfortable enough to ditch my previous editor for good.
|
| OK, but you can be productive with Eclipse or Jetbrains
| (or even Emacs) in an afternoon. This implies to me that
| they're easier.
|
| For me, it also took a few months to get to the point
| where I felt comfortable getting rid of Emacs and use Vim
| for everything, but it only took me a few days to be
| productive with Emacs initially. The swap was worth it,
| but it was a steep learning curve.
| johncoltrane wrote:
| Eclipse and friends are more approachable than Vim
| because they all follow the same familiar model. With so
| much of the core in common, newcomers and switchers have
| very little to learn to use those tools efficiently.
|
| Vim being a modal editor, it is very unfamiliar to
| newcomers and switchers so they have a lot more to learn
| to use it efficiently.
|
| But "little to learn" doesn't necessarily mean "easy to
| learn" and "a lot to learn" doesn't necessarily mean
| "hard to learn". In practice, "little to learn" means
| "easy to pick up" and "a lot to learn" means "hard to
| pick up", which is something else entirely. Eclipse,
| IntelliJ, VS Code, etc. are definitely easier to pick up
| than Vim but that doesn't make Vim "hard to learn" at
| all. It just means that, if you want to get something
| done quickly or don't want to invest too much effort into
| it, Vim might not be the most appropriate tool in the
| toolbox.
|
| Take Sublime Text, for example. It followed a familiar
| editing model but its documentation was so lacking that
| members of the community had to put up an alternative
| doc. ST was (I have no idea how it fares today)
| definitely "easy to pick up" but also "hard to learn",
| all because of poor documentation.
|
| Obviously, the modes, the wonky ways to copy and paste,
| etc. have always made Vim "hard to pick up". But with
| vimtutor as a first step and the very well written and
| progressive user manual as a second step, it _actually_
| is "easy to learn". There is literally no obstacle beside
| one's own laziness or lack of focus or something external
| out of one's control. You _really_ move from super basic
| stuff, to less basic stuff, to cool stuff, to mind-
| blowing stuff in the most gentle, step-by-step way. The
| user manual is awesome.
|
| In short, Vim is easy to learn and it has a very smooth
| learning curve.
|
| The things people have trouble with are:
|
| - the off-putting unfamiliarity of the first contact,
|
| - the lack of menus and things that would make it easier
| to pick up,
|
| - the unfounded expectations, reinforced by social media
| bullshit,
|
| - the unfounded fears, reinforced by social media
| bullshit,
|
| - the perceived need to be productive right now,
|
| - a general taste for battery-included things,
|
| - a general confusion between "learning about something"
| and "learning something",
|
| - a general aversion for learning and, mostly, being
| taught,
|
| - and for reading,
|
| - the false impression of being smart enough to get it
| without learning,
|
| - a goal-oriented approach that seems to justify every
| fucking shortcut ("I'm a React Dev, give me a config,
| plz."),
|
| - etc.
| antiframe wrote:
| I just "purchased" the book on Gumroad for $0. On page seven it
| states "This work is licensed under a Creative Commons
| Attribution-NonCommercial-ShareAlike 4.0 International
| License". Not sure how it's predatory.
|
| Aside: To any newbies that want to read the PDF or Epub version
| and it's no longer free on Gumroad, hit me up and I'll send you
| a copy.
| Timpy wrote:
| People write books about things, I don't think they're preying
| on anybody. It looks like all the material is free on the site
| anyways but you can pay for an ebook if you want.
| johncoltrane wrote:
| > People write books about things, I don't think they're
| preying on anybody.
|
| Lots of books are written about things people are anxious
| about or afraid of in the sole purpose of banking on those
| anxieties and fears.
|
| Step 1: convince vim-curious people that a) it will turn them
| into elite hackers and b) that it is freaking hard to learn.
|
| Step 2: capitalize on the tension created at step 1 by
| providing them ways to skip b on the way to (imaginary) a.
| yash1th wrote:
| it's really harsh to say that. I'm sure many people appreciate
| the material and effort
| ketanmaheshwari wrote:
| Not to take away anything from this but I think there are
| plenty more valuable resources available for free on the web
| on this topic.
| sundarurfriend wrote:
| The author (OP of this post) has a page listing some of
| those free resources available on the web:
| https://learnbyexample.github.io/curated_resources/vim.html
| johncoltrane wrote:
| People appreciate lots of pointless things, and people like
| to profit from it. Such is life.
| ketanmaheshwari wrote:
| vim user manual in pdf form is surprisingly difficult to find.
| Here is one I found: https://begriffs.com/pdf/vim-user-
| manual.pdf
| johncoltrane wrote:
| It's already in Vim, where it matters, so there is no need
| for such a thing. First, because it may not be up to date
| (current version is 8.2, with 9.0 around the corner), second,
| because the links to the reference manual are dead.
| uhtred wrote:
| I always use https://vim.rtorr.com/
| rendall wrote:
| Great job on this!
|
| > _what is all this need for complicated editing features? Why
| does a text editor require programming capabilities? Why is there
| even a requirement to learn how to use a text editor? Isn 't it
| enough to have the ability to enter text, use
| Backspace/Delete/Home/End/Arrow/etc, menu and toolbar, some
| shortcuts, a search and replace feature and so on? A simple and
| short answer -- to reduce repetitive manual task._
|
| For me, the entry way, what convinced me to try Vim, was the
| advantage of not needing to move the mouse. That back and forth
| movement - lifting my hand, grasping for the mouse, moving the
| cursor to where it needs to be, clicking and dragging to
| highlight text, ctrl-x, moving the cursor to where it needs to
| be, ctrl-v, repeated throughout the day just felt inefficient.
|
| But what really makes it feel like a super power is the
| repetitive tasks thing. Convert hundreds of dates from dd.mm.yyyy
| to ISO 8601? No problem! Alphabetize those lines? Can do. Convert
| that Jira ticket title to a git branch name? It's done already.
|
| But "repetitive tasks" would never have convinced me to try it.
| "Just use cut and paste", I would have countered.
| chockchocschoir wrote:
| What finally made me switch was not seeing people editing with
| vim, but rather how they moved around and navigated, which
| seemed so much faster than any other editor.
| systemvoltage wrote:
| What's the best way to rapidly move around without having to
| count lines? I sometimes use Ctrl + U and Ctrl + D to move
| entire pages but always found it a bit more laborious to move
| around in Vim. 13j seems like it would require me to count
| exactly 13 lines before I can get there.
|
| I use vim + mouse unfortunately because it is quicker unless
| there is a better way?
| drekipus wrote:
| There is Lightspeed, which is a buffer search tool thing,
| bound to `s`.
|
| It's pretty nice, but to be honest I just use `/` and `n` a
| hell of a lot. And `j` is probably my most used character. :)
| hermitdev wrote:
| > What's the best way to rapidly move around without having
| to count lines?
|
| Don't? Just turn on line numbers with `set nu`. Add it to
| your `.vimrc` for a default. In a pinch where you need to
| copy/paste graphically in your terminal and don't want the
| line numbers on? `set nonu` to turn them off again.
|
| Sibling comments also have great solutions/different ways of
| navigating.
| dbtc wrote:
| I use { } to move by paragraph/block quite a bit.
|
| / or ? to search forward or backward.
|
| C-f and c-b to go a full page. U and d are half.
|
| But for me it's not only about speed. I guess it just feels
| nice to use the keyboard, even when it's a little slower.
| knowmad wrote:
| I use: H move to the to of the current view M move to the
| middle of the current view L move to the bottom of the
| current view
|
| The way I remember them is (H)igh, (M)iddle, (L)ow
|
| Also setting fold to indent and collapsing the whole file
| with zM is super helpful for navigating large files.
|
| Lastly I use searching a lot with / or ? To just type the
| pattern I'm looking for # to search for the word under my
| cursor.
| StuckBoy wrote:
| #G (i.e. 20G) would put the cursor on line 20, but that's
| only useful if you have line numbers in your editor. If you
| have relative line numbers then #j movement is easy since the
| number you need to jump up or down should already be
| calculated.
| systemvoltage wrote:
| I did turn on relative line numbers and still feels
| laborious compared to mouse click which happens within 500
| ms.
|
| Say I want to go up by 13 lines and on the 4th word:
|
| Step 1: Scan visually on the left gutter for a line number
| (relative or not)
|
| Step 2: 13j
|
| Step 3: 3e (3 words to the right)
|
| Everything else in vim is fast except navigation for me.
| With mouse, it is a little bit of a pain to move the hand
| over to the mouse and the click, but still feels orders of
| magintude faster than jumbling around with line numbers.
| aidos wrote:
| I mostly use / and ? for jumping about in the code. It's
| always just a few keystrokes and you're where you want to
| be.
| rendall wrote:
| > _What 's the best way to rapidly move around without having
| to count lines?_
|
| oooh. I have a treat for you! Check out "hybrid line
| numbers". I thought they would be weird when I heard about
| them, but they're awesome, and I never need "absolute line
| numbers". But the linked article shows you how to set up
| toggling if you need them.
|
| Basically, they look like this: 3 Lorem ipsum
| dolor sit amet, 2 nunc in iaculis ipsum. 1
| Suspendisse dapibus odio erat, 98 non varius nulla
| porttitor at. // <-- You are here 1 Nullam in convallis
| elit. 2 Sed nec venenatis ligula. 3 consectetur
| adipiscing elit. 4 Sed hendrerit ac ante sed viverra.
|
| In this example, your cursor is at line 98 and so shows the
| absolute line number. The other lines are relative to your
| current line. If you want to go down to the line that starts
| _consectetur_ , you see that it is below you 3 lines. You
| have to type _3j_. If you need to find a specific line
| number, say 24, type _:24_
|
| Here's an article on them: https://jeffkreeftmeijer.com/vim-
| number/
| sundarurfriend wrote:
| A lot of the time, you want to be using a more meaningful (as
| in semantic) command like } or ]] or / - my Vim navigation
| improved a lot once I started understanding / as a navigation
| command i.e. a "go where I know this text is" rather than
| just "find where this text is".
|
| But when you do need to move by lines, `set relativenumber`
| is very helpful. I have both `set number` and `set
| relativenumber` in my Vimrc, so I get relative numbers for
| all other lines except the current one. For the current line,
| the absolute line number in the file is displayed (which is
| more useful than the relative "0").
| doix wrote:
| When I open a file, I fold everything (zM) to get an overview
| of the file. Then I slowly unfold as I'm browsing, ignoring
| the parts I don't care about. I set the repeat delay super
| low and repeat rate super high on my keyboard and just
| navigate around by holding j/k or {/} (for large folds).
| Since everything is folded, you're moving about pretty
| quickly.
|
| If you're looking to use the 20j stuff, you can `:set
| relativenumber` so that vim shows you line numbers relative
| to the selected line to avoid counting. I couldn't get used
| to it.
|
| There's also Hop[0] if you want to go the plugin route.
|
| [0] https://github.com/phaazon/hop.nvim
| agentwiggles wrote:
| I've always wanted a sort of "hybrid" line numbering
| scheme. Show me the relative numbers in one column, and the
| absolute line numbers in another column. You can set up vim
| so that the absolute number appears on the line your cursor
| is on (and the other lines display relative nums) but this
| isn't quite enough.
|
| I want both, dammit!
| silent_cal wrote:
| What is the point of Vim? I have used it before and to me it just
| looks like an antiquated text editor. But I'm sure I must be
| missing something.
| phailhaus wrote:
| You probably don't need it. I like it because it's lightweight
| and always available in my terminal, and the modal paradigm of
| editing is very well suited to editing code. It's more like
| modifying the structure of the code rather than working at the
| character-level.
|
| However, I've spent years finding the right set of plugins,
| shortcuts, and keybindings that work best for me. I've
| basically turned it into an IDE for myself, but one that I can
| navigate much more efficiently than something like Pycharm
| (even with vim mode).
___________________________________________________________________
(page generated 2022-03-15 23:01 UTC)