While I appreciate your comment, we can already guess that you believe the packages you have chosen to be “the best” at their job. Without further narration (and I’ve only singled you out due to being the topmost comment), comment sections like this have a tendency to become a dumping ground for vimrc snippets.
Could you expand on why? Personally I’d be particularly interested on your thoughts about vim-plug, as I use pathogen currently and I seems to do everything I need.
Lots of people like plugin managers. I prefer to use "git clone" and "stow". Much less magical, and I feel I have a better understanding of what's going on with my configuration.
I have a plugin manager that can help you with that!
Seriously, isn't part of the problem that vim by default looks for all plugins in one directory? Tim Pope's Pathogen does the minimum here and lets each plugin have its own directory (which translates to git repo). You're responsible for going to each directory and updating them.
I'm doing that too. I clone into "~/.config/nvim/stow/", then stow figures out how to put all that stuff into the proper places. Occasionally there is a conflict, but that is usually for files that I don't want anyway, like "build" or "LICENSE".
Plugin managers are also nice because you can maintain a list of plugins right in your vimrc. Not the biggest win in the world if you are fine managing your plugins via a shell script, but it's a win to many.
My favourite thing about vim-plug is its `:PlugDiff` command which, after running `:PlugUpdate` will load all the new commits in an explorable vim buffer, so you can see exactly what changed and even easily see code changes.
Those were my favourite neovim plugins as well. Oni is still a bit rough around the edges, and rendering is a little bit slow at times, at least on my machine.
Overall, it's a solid alternative to Spacemacs that not enough people know about.
Spacemacs markets itself much better and I tried it first, but found it to be bloated to be point that it noticeably impacted performance. E.g. start-up time was 10+ seconds; ~2s with doom (and doom doesn't feel any less feature-complete).
As for the bus factor, doom has the maturity of a 4-year-old project; it won't just fall apart on you. It is mostly a one-man show, but Henrik is still very active and super quick to respond to issues.
What is the downside of using vim packs in contrast to vim plugins ?
I just do cd ~/.vim/pack/start and from there I git clone the repos and that's it...
In my case I usually work in a container and have different packs depending if I'm doing stuff with programming in rust or go or just do configuration management.
I really loved the asynchronous functionality in vim8, any nice plugins that take advantage of it?
For now I only use it to trigger cargo test and let finish at some point later on:
https://github.com/sebosp/linuxtweaks/blob/develop/vimrc#L14...
I gave up trying to make Vim into an IDE. It's a text editor. It's an excellent one, but that's what it does. The plugins just aren't very good. NerdTree is not a good file browser. None of the autocomplete/intellisense works very well. It does work, but requires a lot of setup, and let's be honest, a TUI isn't the best way to interact with autocomplete dropdowns.
Most of the IDEs have vim like features or plugins. It works a lot better the other way - make your IDE into Vim.
I've never liked nerdtree, everybody seems to suggest it but I never saw any utility in what it does. Why would I want a filebrowser taking up an entire window in vim when I have wildmenu command line completion for :e and, for deeper directory trees, fzf (although I only started using that recently, nerdtree never made sense to be before then either)?
I do wonder what your gripe with the autocomplete dropdown is though, vim's built in TUI completion dropdown (this isn't something plugins invented, it's in Vim by default) seems to work just fine for me. The only completion plugin I use is supertab, which I understand to be dated and out of vogue these days, but it gives me continuity with command line completion being triggered by my tab key. The dropdown works exactly like I'd expect it to; tab and shift-tab to cycle up and down, and enter to select a completion. If I continue typing with it open, it refines the suggestions on the fly. I'm not sure what else I should ask for.
For everz we've ben trying to shove one into the other.
Every IDE has a sort of shitty text editor.
Every text editor tries to make a shitty IDE.
Can someone please ackgnowledge that the reality is that neither is a good approach? I wish that I could have complete integration between VIM and JetBrains suite. Would be nice if the JetBrains platform could render a VIM inside itself as the actual text editor but kept 100% of its features as vim plugins to be installed. That way nobody has to re-invent the wheel on great text editing (emacs falls into this category too) and actually making intelligent IDEs.
This is the goal of the Oni project, but it's still early in development and there's lots of work left to do. Yes, it's electron but in my experience it never uses more than a few hundred MB of ram.
Oni is my current text editor, and even though it's pre-1.0, it's been a fantastic experience. It starts fast, looks great, works perfectly as a Vim (it supports standard Vim plugins), and requires almost no configuration (I don't know why the built-in Prettier code formatting is shipped disabled, but you should turn it on).
Neovim promises to close the loop and finally bring balance to the world, but whether or not those lofty goals are realized in practice remains to be seen.
I've tried using vim plugins with different editors before, but they're always missing a few of the shortcuts that are in my muscle memory and drive me crazy.
Also, being able to ssh into any machine and remotely edit code is pretty awesome.
The biggest thing for me when trying to switch from console vim is `alt + <key>` will send ESC and the key, so you can use alt to exit insert mode and send a command at the same time. Doing alt+j or alt+k has become the way I always leave insert mode (or command, or visual).
Unfortunately most IDEs that have vim keybindings don't support this, and it has become such a baked in part of my muscle memory that it makes switching to anything else such a pain.
Many of them fail to implement macros in my experience. Though I've heard VSCode got this part right.
The most productive vim keybinding I ever came across was:
noremap <Space> @q
Since the key to start a macro is q, you can quickly tap qq to record a macro to the q register (end it by pressing q again.) Then by whacking the space bar you can execute the q macro as many times as you'd like. Once you get into the rhythm of using it often even for small tasks, it can become a great optimization. Sometimes I use it with five or more different macros in a single minute. If you ever look forward in time and see that you're about to perform the same edit two or three times, pressing the q key three times total and the space bar once per execution (or only once with a count) will often be fewer keystrokes than had you performed the edit manually each time. Not to mention triumphantly smacking the space bar to repeat an edit is a great feeling.
(Simple edits can be repeated using . which is another indispensable vim feature that sometimes gets missed by vi-plugins in other editors.)
Since <space> is some peoples' leader key (not mine, but I see it a lot), just throwing it out there that `Q` is a fine alternative for that mapping too. It's also a nice semantic companion to `qq`! ...unless you are a heavy ex-mode user, of course :)
If you want a "file drawer" that is always open, nerdtree ain't great, but furthermore, the whole "file drawer" concept doesn't really work in vim. I personally prefer nerdtree to the builtin netrw but the "killer setting" for me is "close nerdtree after opening a file". nerdtree is super useful as a tree explorer but you'll have a much better time if you don't treat it as a "drawer".
Vim for me is an editing style. It's more powerful than using arrow keys/alt/ctrl for navigation. Wherever I edit, I just need that editing style.
The vim editor gives you only the editing style. VS Code on the other hand gives you that editing style (arguably less powerful, but good enough for my needs) plus a whole lot of other things without much configuration. I'd choose VS Code anyday
I gave up too: I wanted to replace Eclipse with gvim but vim doesn't use efficiently multiple tabs by default and it would take a lot of configuration to change this..
I don't see why being effective in vim means you ^z out of vim to run `ack` or `grep`, instead of pressing ^f (for example) to run Ack.vim on the <cword> and have the results displayed next to your code in a window that, when you select the item you want, opens that corresponding file in a buffer with your cursor already on the line in question. Certainly you don't need ack.vim, you could just ^z and do it the old fashioned way, but where is the utility in that?
As for the unix philosophy, it's all about programs doing one thing and doing it well... but isn't it also about composing those programs to do the job you need done? If you're just ^z'ing out of vim to run `grep` or `ack`, how do you get those results back into vim? copy/paste it through your terminal emulator, using tmux in the best case scenario? How is that more in line with the unix philosophy than simply having vim shell out to those utilities for you?
^z to run unix utilities is like coping the output of one command into a file on disk before sending it to another, instead of simply piping the output of one into the input of another using the functionality of your shell. If vim filling in for a shell violates the philosophy, then damn the philosophy. I'd rather have "the traditional shell+domain specific shells(vim, ranger, etc)" than turn the traditional shell into a one-size-fits-poorly shell.
https://github.com/mileszs/ack.vim (Because ack.vim and plugins like it are actually in keeping with the so-called unix philosophy for reasons I outlined above, you don't actually have to use `ack` with ack.vim. I use it with `ag` (the silver searcher) instead.)
>Certainly you don't need ack.vim, you could just ^z and do it the old fashioned way, but where is the utility in that?
Because ack.vim can't be piped into other tools. You can't, for example, limit your search to the last 50 files modified. Or only to executable files. You can't pipe the results into sed or make matching files world-readable. Sure, you could install ack.vim, slow down vim's startup and bloat your installation, or you could just hit ^z and use the unparalleled power of the Unix shell.
>How is that more in line with the unix philosophy than simply having vim shell out to those utilities for you?
Sometimes it's not. But vim has ! built in, you don't need plugins to run commands from it. I do it all the time.
> "or you could just hit ^z and use the unparalleled power of the Unix shell."
Or I could use both, when the need arises, which frankly it never has for me. Ack.vim does not preclude using ^z when you have a special need, it optimizes the common case. And Ack.vim is much nicer than !ack <cword>
> "install ack.vim, slow down vim's startup and bloat your installation"
Well I don't run vim on a z80, so the difference would be pretty hard to measure ;). The way modern well-coded vim plugins like Ack.vim work involves lazyloading using 'autoload' (which is poorly named.) Ack.vim includes plugin/ack.vim (p/av) and autoload/ack.vim (a/av). p/av loads when you start vim, but is a light-weight file that only contains keybindings and settings variables. The actual code of Ack.vim, the function definitions, exists in a/av which is loaded lazily, when one of those functions is called by a keybinding created in p/av.
"simple things should be easy, hard things should be possible."
I rarely (if ever) need to make matches world readable from the context of text editing. When I do, there's nothing stopping me from using ^z, but until that day comes, a plug-in is going to be fewer keystrokes, faster, and better integrated with what I was already doing.
One thing I don't understand, is how do you handle mistakes with the 'unix-as-ide' approach? I was using sed to refactor. Now, I typically use bufdo %s/foo/bar/gc, because it's much more forgiving. It's the same story with a lot of stuff you can ctrl-z for - if you can do it inside vim, it's usually far easier to control and roll back.
Strictly speaking, one doesn't even need a plugin to use ack, ag or ripgrep from Vim. It is enough to set the "grepprg" option (perhaps also "grepformat") and then one can invoke the built-in ":grep" command.
:grep is what I used originally and found it unsatisfactory; eventually I switched to my own keybinding for !ack <cword>, then some time after that switched to Ack.vim with ag.
> effective vim users ^z out of vim and use Unix as their IDE.
As someone who used to do this, I can tell you it's not very effective. For example, build systems. I work with a lot of C++ code, and after making changes I used to ctrl-z to the terminal and then `make` manually ... only to get blindsided by lines and lines of error messages, many due to a lot of trivial syntax errors. Using YouCompleteMe may not be very minimal or "Unixy", but having error messages inline with my code and being able to correct them as I work is invaluable. Maybe your experience is different, but I couldn't get it to work for me. ¯\_(ツ)_/¯
I personally use no plugins [1]. Zero friction moving from host to host. Vim is a great text editor, not a great IDE. For anything more sophisticated I prefer just switching to something like VS Code (with Vim bindings of course).
I've never really understood this argument. Using vim locally with a bunch of plugins and then vanilla vim remotely is really the exact same thing as using any other editor locally and vanilla vim remotely.... especially if you are using vim bindings in said other editor!
In any event, I just mitigate this problem by not overriding a bunch of standard behaviour. Also, none of the many plugins I use modify any standard behaviour in any serious way, they just help speed up certain actions when working in a large code base. There is very minimal context switch for me when editing a file remotely.
Same. I had quite a lot some time in the past, but also made the "using vim on some foreign machine and being confused as hell" experience by trying to use hotkeys or commands that didn't exist. Also just keeping the config synched between my own hosts was more annoying than I anticipated. Not to mention resolving conflicts between different plugins, or random stuff breaking when updating anything.
Nowadays I have a vimrc that just tweaks vanilla features the way I like, plus some highlighting for certain keywords regarding a C codebase I occasionally work on. The only plugin I use is a modified version of DetectIndent.
> "Same. I had quite a lot some time in the past, but also made the "using vim on some foreign machine and being confused as hell" experience by trying to use hotkeys or commands that didn't exist."
I've found that setting a custom colorscheme in vim averts this problem completely. If I see my colorscheme, my muscle memory is primed for my config. If I see the default vim colorscheme, my muscle memory reverts to default vim.
If somebody gave me a copy of otherwise vanilla vim to use that had my colorscheme, that would certainly throw me for a loop. But so far nobody has been that diabolical.
It's really non constructive to think sticking to the painful default config of vim as a virtue. Why don't you just copy your vim config around? or if you're sharing users, ask to create your own user or just source your own config when you're using it.
People seem to swear by NerdTree, but I personally don't see the purpose of it. Sure it may be nice to see your file structure sometimes, but having a terminal open or even just the actual folder window open solves that. Everything else can be done with the built-in :Ex command, which lets you navigate to open files, create new files, rename, delete, mostly everything you want.
As for other plug-ins, there are a few I would recommend (can you tell I'm a Tim Pope fan?):
- VimCompletesMe: A much more bare-bones auto-completion tool than YouCompleteMe, hitting tab gives you matches from your previously typed text. It's also all in vimscript so it's much easier to install and manage: https://github.com/ajh17/VimCompletesMe
- Pathogen: A plug-in manager, if you can call it that. It simply re-adjusts the file paths so you can centralize your plugin directory. Some plug-in managers will auto-update, but I never liked that, just run git pull if you wish to update a plugin: https://github.com/tpope/vim-pathogen
There are some other cosmetic ones I like as well, like airline, and vim-highlightyank, but that's a personal preference.
I'm not a vim user (yet), but this feature is built into Atom and I've come to find it indispensable. I'm a bit of a commit diff freak (I like it neat and tidy), and once i've finished messing around on some branch I want to gradually converge to some simple differences, a git diff type gutter is really helpful in visualising ("watch git.." can come close but nothing is as good as in editor integration).
How is the plugin management in vim? I use emacs and it’s a pain to setup. You need to modify a config file (.emacs) in order to add plugin lists (melpa). You then browse the list through a shortcut (M-x list-packages) and you only see names, no description or ways to look for something specific. Once you installed your plugins there are no real way to access a manual or learn them. Often you will need to modify config files to make them usable.
The Emacs package list has a description field on the right, a shortcut for more info (?) and after it's installed you've got C-h m and often info pages (C-h i). What's wrong with that?
Vim has no unified plugin structure, there are several plugin manager packages (often installed via git clone). I personally use vim-plug[i] which is more on the minimal side, but there are others like pathogen or vundle. No real centralized plugin repository like melpa, I don't think one of the plugin managers I've used had some kind of common install-screen. You mostly enter the github address and execute the package update vimscript. I've seen more Emacs info packages than :help docs, but in most cases I'm browsing the githup README.md/.org anyways.
Your comment is totally wrong. Any package that's more than a quick hack has inline documentation in a ;;; Commentary: blog, docstrings for all public variables and functions, and customisation options for setting variables with an interactive interface w/ documentation and accepted values integrated. Bigger packages come with info files. All sorts of help is accessible by a multitude of entry points, most bound to convenient and consistent shortcuts. Package system requires remote repositories just like any other package system, and Melpa is a third party repository, so that's not surprising at all. The GNU Elpa archive is configured by default. And the list-packages interface has package descriptions, and can show package details by a single keystroke. Selecting and installing/removing multiple packages is possible.
If configurability is a burden on you just quit Emacs because that's its biggest point which makes it a very productive tool. And just like a sponge won't clean your tabletop by itself if you don't put soap on it and rub it to the tabletop, Emacs can't do anything for you if you don't learn how to use it and actually use it.
On Emacs, if you hit enter on a package after running (M-x list-packages), there's usually a brief summary and a link to Github. After you install the package, you have lots of commands to access documentation. Here's some of them:
C-h i: info manuals
C-h ?: help for help
C-h F: help for commands
C-h v: help for variables
C-h f: help for functions
C-h m: help for minor modes
Nearly all vim plugins worth a damn come with documentation that integrates smoothly into vim's help system. That vim plugin developers care enough to write such documentation is a credit to vim's plugin culture.
I’ve moved from YouCompleteMe to Deoplete. While YCM is good, the plugin support for deoplete seems a bit more extended and easier to set up (ymmv). Maybe I just messed something up every time I tried to rework my vimrc with YCM though, it’s probably likely :D
I've doubted for long about learning Vim or Emacs.
I like the default vim keybindings, but I don't like having to install plugins in order to make my editor usable, I like the batteries-included concept.
But when I try to learn Emacs I can't accept the fact that I have to press M-v to go up one screenful. It must become really uncomfortable really fast.
I spent a day or two recently figuring out how to get the vim-airline (aka powerline) icons to work properly, going through pretty much every single font/theme option on Windows (even in the DOS prompt) and Linux. I added a dummies guide [0] to the Wiki.
For a Windows console user - it's worth noting that since they got 24-bit colours working in the console the work is now on-going to get the colours properly working in terminal Vim [1].
that would require actually understanding the code. it could be done i guess these days with the async that came in 8.0 but would require some pretty heavy vimscripting.
As an Emacs user, I'm so curious about vim packages. Does vim have packages that are akin to adding a major mode in Emacs? Some of the packages on this list look like the vim version of minor modes or little helper functions.
Vim has a limited number of "modes" -- insert, normal, command and visual. These are not analogous to Emacs modes AFAICT. A vim package/plugin typically modifies/enhances behaviour in these modes. Where they can, useful operations are bound to a key combination.
You spend most of your time in Vim (when editing) in normal mode, executing deft movements and register usage to behave as a surgeon upon the text, as it were. Vim's noun/verb with multipliers make this an effective editing paradigm. Enlightened users have reported "thinking in Vim."
Vanilla Emacs to a vim user feels like you're always in "insert" mode. Chording everything felt a little weird, and I gave up on evil-mode because it wasn't vim enough for me.
Right, I am an evil user myself. My question was about the vim equivalent of major modes in Emacs --- Does vim have a concept of major mode (a set of language specific functionality, one major mode per buffer)?
Not formally in the Emacs sense, but you can of course have configuration only load depending on the filetype so you end up with different keybindings (or other settings) depending on what sort of file you're in.
I came across this before but since I was using tmux splits back then, this sounded like unnecessary overhead but now that I've been using vim splits excessively, this is proving to be a nice little addition.
And you waste 95% of the time you use your own vim with painful default? Some people seem to want to live by your statement but I treat it pointless. Just pretend the default vim is another editor and live with your customized version.
hmmm. i dont use any myself (i tried omnisharper and the java equivalent for more quickly finding syntax errors but quickly dropped them as they are unreliable).
here are some plain vim alternatives:
1. goyo: i write markdown quite a bit. it is not necessary to have much for this except perhaps syntax highlighting. hiding the status line can likely be done with a few configuration directives.
2. gitgutter. for the described use case:
<ESC>:new<ENTER>:read !git diff
use the search :/ to go from one diff to the next
3. vim-surround
for a word: (<ESC>wa)
for a line: (<ESC>$a)
depends on the situation, but i'd need more to be sold to use this plugin.
4. vim-autoclose
as described here it might possibly be nice except if you have to write a smiley, an arrow, or similar. if you never need to i can see this being useful, but the effect is quite minimal, as going to the end of the current line is a matter of <ESC>$ and inserting a closing parenthesis after it is a matter of a) .
5. vim-commentary
visual block mode is sufficient for this usually.
java:
(<ctrl>+v)<ESC>$g$0i//<ESC>
6. the gruvbox color scheme looks pretty neat. however:
the built-in desert scheme works well on almost every machine and is included by default, so there is no real need to go to this amount of trouble. if you work regularly under a shared root account via ssh, i think it is wise to stay away from custom color schemes.
7. could be useful actually, i might try it. however find and grep and other external tools can be used from vim as well. the only gain by using this is that results appear as you type instead of after. marginal gains.
<ESC>:new<ENTER>:read !find -name 'bla'
8. i think the preinstalled netrw plugin is just fine for exploring. it can be configured to run in a treemode too with some configuration. and the advatage is that it will be available on your average shared server account as well, so it pays much more dividend to learn netrw over nerdtree.
9. sounds like a simple remapping. you could just use the default key <ctrl>+p . the nice thing is that this will be available on shared servers.
10. importing is pretty easy already. here is how i do it.
importing
<ESC>1giim<ctrl-p> whatever
dropping
<ESC>/import\ what*<ENTER>dd
* FZF. Perhaps the best fuzzy finder for Vim https://github.com/junegunn/fzf/
* ALE. Asynchronous Linting Engine, totally awesome. https://github.com/w0rp/ale
* Polyglot. A "best of" language pack. https://github.com/sheerun/vim-polyglot
* Plug. IMHO the best plugin manager going https://github.com/junegunn/vim-plug.
* Fugitive. The best git wrapper there is https://github.com/tpope/vim-fugitive
* vim-test. A plugin that helps you run tests from inside of Vim. https://github.com/janko-m/vim-test
Outside of that, switch to NeoVim if you haven't already (https://neovim.io/). Or give Oni a chance, it looks really promising (https://www.onivim.io/).