6 ms·
> "move the cursor to a certain place and enter some text" In vscode, I'm usually already looking at the call site of a function I want to edit. So I move the
by wayneftw 7y ago
> "move the cursor to a certain place and enter some text"
In vscode, I'm usually already looking at the call site of a function I want to edit. So I move the cursor into the function call and hit F12 which takes me to the function definition to edit it. Once I'm done, I hit Alt+LEFT to navigate back to where I was to continue on...
If I didn't start from a call site but I know the file I want to edit - I hit Ctrl+P, type the name of a file, hit ENTER - now I'm in the file, ready to edit it.
To jump to a function, I collapse all functions (Ctrl+K,Ctrl+0/1/2/3/4) and then scroll (or PAGE UP/DN) to find it...then use arrow keys or Ctrl+G to enter the line number. Now I'm ready to edit the function. I might have to hit Ctrl+Shift+] to expand the body of the function.
Alternatively, I Ctrl+F and type the name of the function I want to edit, pressing ENTER to find it...and I'm ready to edit the function.
What do you do in vim that is far easier?
- deleted 7y ago[deleted]
- nik_0_0 7y agoReading the parent comment (and being somewhat a vim user) - "move the cursor to a certain place and enter some text" - sounds mostly about the first thing you mentioned - "move the cursor". Stock vim is mouseless, and without arrow-keys, which means relying on /? (searching) or other keys to achieve the function of arriving at text. CTRL-F never quite matches that (after you hit enter, the CTRL-F dialog is still open, and needs to be closed with ESC or by clicking away), and moving to the arrow keys/pgup/pgdown/mouse is slow. Having said that - there are some plugins that match this behaviour - I particularly like the ones where a key (f in vimium) highlights each word with a character, allowing for one or two keypresses to jump anywhere on the screen.
- savanaly 7y ago>So I move the cursor...What do you do in vim that is far easier? The part about moving the cursor. Vim users typically don't move the cursor with the mouse but rather with the keyboard. Having to move your hands off the keyboard to reach for the mouse then back is the part that starts to feel sluggish if you get used to not doing it.
- dmitriid 7y agoBefore a vim'er finishes typing yet another command to find that one specific text, a mouse user will have already clicked where needed :)
- viklove 7y agoQuite the opposite actually, by the time your hand even finds the mouse the vim user will already have jumped to the desired code block and have started editing it.
- dmitriid 7y agoHaving worked alongside longtime vim users, that's almost never the case. There's often more time spent on finding out/remembering the efficient way to get to a particular piece of code. And then there are the inevitable mistakes (oh, I counted give spaces/quotes/paragraphs, but there was one more/one less; oh, I failed to account for some minor thing in my macro etc.). In a modern IDE you have a multitude of shortcuts and a mouse, and they complement each other.
- viklove 7y ago> Having worked alongside longtime vim users, that's almost never the case. There's often more time spent on finding out/remembering the efficient way to get to a particular piece of code. Longtime vim users who didn't know how to use vim? That's... interesting.
- edanm 7y agoIt's not so much the moving between the files - which vim is terrible at (one of the many things I had to extend in vim in order to get it to work like an IDE). But it's moving and editing within the file itself. E.g., say you somehow got to a file, and it now has a bunch of functions in it, and you're literally looking at the line you want to edit. To get to that line, there's a bunch of different ways, but you can do this in like 3 key presses. Then, within the line, you can change anything in it really easily. This sounds weird, so I'll try to give an example. Let's assume you have something like: Func(self._something, self.something_else).validate, 'Validate exam foundation table') And let's say you want to change the string that says 'Validate [...]' to say 'Change is good!!'. To do that, once you've gotten to the line, I'd probably hit two key presses that mean "go to the first open quote in the line", then I'd hit the keys that mean "delete everything inside of the quote character", then I'd type what I want. All in all, I'd be typing these characters before actually writing what I want to write: f'ci' (so, 5 characters). That probably looks either idiotic or daunting - but the idea of vim is that it's a language - you are literally thinking in your head "go to that quotation mark", then tell vim to do that and it does. Then you're thinking "delete everything inside of these quotations", and it does it. The distance between thinking what you want to do and doing it is almost zero - it's as close as you can get to literally telling someone exactly what to do. If you're using a non-vim editor, you'd probably have your cursos in the begining of the line, and have to do "cmd+right" several times to skip over words in order to get to the first word of the string, then have to "shift+cmd+right" to get to the end of the string, then write what you want. There might also be some small annoyances - the last shift+cmd+right might take you over the last quotation mark, and you'd end up selecting the closing paren as well. In vim - that doesn't happen, you're saying exactly what you want to have happen. Or you might want to undo this change - in vim, it's always hitting "u" once, because in vim, changing the string to something else is an atomic motion. In another editor, you might have to undo a few words at a time, or maybe not - it's not always predictable. And since it's atomic in vim, it's also easy to re-apply the same action to another string - so changing another string to the same thing is a simple matter of hitting "." on it. And of course, this is just a tiny example. It's easy to dismiss as trivial or unimportant - these are tiny savings of time, after all, and even if you add it up, I doubt the "time saved" in doing things more efficiently is worth much. But once you know this language for telling an editor exactly what to do, then using an editor that doesn't speak that language just feels super slow - it feels like you are not able to communicate properly, and suddenly, what used to be zero gap between thinking and doing, takes a long time.
- stevelosh 7y agoYou're talking about how it's easy to move to a function or a file, and then you're "ready to edit", but edanm is talking about actually doing the editing. For example: say I jump to this function and want to fix a bug (the `search` should strip off the first two characters here, not just one). So I need to change `regex.search(s[1:], ...)` to `regex.search(s[2:], ...)`: def compile_hg_glob(line): pat = glob_to_re(line) # Mercurial ignore globs are quasi-rooted at directory boundaries or the # beginning of the pattern. pat = '(^|/)' + pat # Mercurial globs also have to match to the end of the pattern. pat = pat + '$' try: regex = re.compile(pat) return lambda s: regex.search(s[1:] if s.startswith('./') else s) except: warn("could not parse hgignore pattern '%s'" % line) return lambda s: True If I've just used a fancy shortcut key to jump to this function, my cursor is probably on the function name. In Vim, I'd do `cinr2:<esc>`. Seven keystrokes. I could also do `/[<cr><ctrl-a>` which is only four keystrokes, but a little more awkward to reach. If I tried to do this editing with arrow keys and backspaces I'd need 12 down keystrokes just to get to the right line. Or suppose I'm looking at this and want to add a `,` character to the end of each of the type entries, because I forgot Python likes its commas: result = result | { 'a': TYPES_ALL 'e': TYPES_FILE_REAL 'x': TYPES_FILE_SYMLINK 'c': TYPES_DIR_REAL 'y': TYPES_DIR_SYMLINK 'f': TYPES_FILE 'd': TYPES_DIR 'r': TYPES_REAL 's': TYPES_SYMLINK }[c.lower()] In Vim I'd press `j` to get to the first entry, then `A,<esc>` to append the `,` after the first one, then `j.` to move down and repeat the action. I then press `j.` a bunch more times (which is really easy to do rapidly with your index and ring finger on Qwerty) and in 2 seconds I'm done. Vim's `.` to repeat the last action is really powerful and can save you a ton of time for small ad-hoc edit repetitions that don't warrant doing a full macro with `q`. These kinds of things happen constantly, and when you've got Vim burned into your fingers trying to edit text without it (actually edit text, not just jumping to something) feels like typing with oven mitts on.
- jiofih 7y ago1: ctrl-f, 2:, esc 2: select the first :, ctrl+d until all are selected, right arrow, comma Doesn’t sound any more efficient? Plus, who writes code without an auto-formatter these days? Problem two would have been solved by the linter the moment you wrote that.
- thawaway1837 7y agoEven something simple like reading code line by line (and of like me you like to move the cursor as you read the line), and your cursor reached the bottom of the screen, and you want reset the viewport where the line the cursor is on is at the middle of the viewport, is one keystroke ‘M’
- s_kilk 7y agoI do all of the same in emacs (and vim), and because I use doom-emacs I get all this basically for free without much configuration on my end. - Go-to-definition is `g d` (with the cursor over the function name in question) - Project-wide file search is `SPC SPC` - Jumping to a function is `SPC s i` and then just start typing to fuzzy-match the function name I stick with this setup because it does pretty much everything I could want from IDEA, and does it without churning up most of the resources on my machine. And trust me, I've tried to switch to IDEA, but it's just too big and too slow, and too poor of an editor for me to actually make the switch.
- scooble 7y agoAll that can be done in vim. The one related function that I would miss is using vimgrep and the QuickFix list to get a list of the locations where the function name appears which I can use e.g. to do a search and replace in those files (or a subset of them)