Anyone using vim-mode plugins for other IDEs? Most vim critic in the comments seems to be against it as an IDE, while the biggest benefit is obviously the keyboard control. So why not use the combination of both (I installed plugins for Visual Studio and Atom a few days ago and I'm quite happy so far, but it's my first steps in to vim, so maybe I'll find things that won't work later)?
Vim for Humans
221–230 of 251 posts
Re: Vim for Humans
#222I'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…
Yip, practical vim is absolutely excellent, I'd highly recommend it. 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... [0] http://vimdoc.sourceforge.net/htmldoc/usr_toc.html
Drew Neill's vimcasts.org is also great.
Re: Vim for Humans
#223A wiseman once told me: "If you have to hold a key to reach your goal, there is probably a better (i.e. shorter) way to do it."
Re: Vim for Humans
#224Earlier quoted context omitted.
Well, it depends on what you're doing. For example, if I want to duplicate a line in vi, I can type 'yyp' and _bam_: duplicate line. With a keyboard and a mouse, I have to reach over, select the whole line (being careful not to over or under select), hit Ctrl+C, move the cursor down to the beginning of the next line, and hit Ctrl+V. If I want to change the contents of a quoted string, I can type 'f"lct"' and start ty…
```f"lct"``` can just be changed to ```ci"``` and it will do exactly that with fewer strokes and is easier to remember and more resistant to where you are wrt the first double quote. (can be remember by change inside ") if you are inside a double quoted string already it will still work correctly and if you are before it on the line it will search forward for it and change the same string. works with ( and { and ' as…
> be changed to ```ci"```
Neat, I didn't know that - thanks for the tip!
Re: Vim for Humans
#225I'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 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.
I'd buy that. Hey, No Starch!
Re: Vim for Humans
#226I wish I could use vim or emacs. I don't know if I'm stupid or something but all of the key bindings, everything you have to remember, it just doesn't make sense to me. 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).
> it just doesn't make sense to me. 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…
> 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.
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.
Re: Vim for Humans
#227Earlier quoted context omitted.
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.
So if we look through the source tree of a random unix I won't find any .h or .c files?
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.
Where are you going with that?
Re: Vim for Humans
#228Earlier quoted context omitted.
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).
Security concerns in the same editor that added non-authenticated blowfish encryption in 2010?
Re: Vim for Humans
#229Earlier quoted context omitted.
That may be, but it's tough to use a customized vim on your local machine, and then switch to a stock install on a server somewhere, no?
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.
Or just clone your dotfiles from a repository.
Re: Vim for Humans
#230Earlier quoted context omitted.
As I mentioned above, I'm not really convinced that numeric repetitions are that useful, because counting instances, even at a glance, is more mental overhead than just pressing a button a few times. Because most of the time I don't want to "delete n words", I want to delete these words, and there happen to be n of them. More generally, my experience of vim is that I'd spend longer working out how to do something wit…
It's not just repetition of say, do this command more times to words. There are more nouns available to apply your verbs to. You can "change a paragraph": `cap`, change the contents of some brackets: `ci(`. I find myself using various permutations of these all the time, and missing them enormously when I'm not in vim. My favourite is `caa` to change an argument in a function call, respecting commas and parens, althou…
>cap, caa, ci(
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.