I dont use fzf but CtrlP for vim is also very good at fuzzy search.
CtrlP enables my habit of having gazillions of buffers open when working on large projects. It’s great with splits.
Intermediate Vim tips
31–40 of 79 posts
Re: Intermediate Vim tips
#32I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.
Same. I spend most of my time in a terminal and SSH into various boxes daily. I do customize my standard Unix toolset, but avoid plugins and non-standard configs that increase cognitive burden. It's very liberating to feel comfortable with shitty defaults. If you feel at home with the defaults, you feel at home anywhere.
You can remotely edit on any system accessible over ssh thanks to netrw:
vim scp://some-remote-box/some/path
:help netrwRe: Intermediate Vim tips
#33Do you even emacs bro?
Re: Intermediate Vim tips
#34I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.
Leverage your tools. Don’t let them leverage you.
Reduce the friction of importing your vim config non-destructively and on demand.
Re: Intermediate Vim tips
#35> I don't like excessively long lines of code (120+ in most languages) Quick straw poll on this... How many people like a line length limit? My personal preference is a fairly strict 80 (barring silly things like URLs), but I've always been met with resistance to ANY line length limit. Is it really that imposing?
I just let them soft wrap.
Re: Intermediate Vim tips
#36> I don't like excessively long lines of code (120+ in most languages) Quick straw poll on this... How many people like a line length limit? My personal preference is a fairly strict 80 (barring silly things like URLs), but I've always been met with resistance to ANY line length limit. Is it really that imposing?
I don't believe in hard limits, but if a line goes over about 120, I'll put its length under more scrutiny, to see if there's somewhere that it would make sense to split it. There almost always is, unless it's some kind of data table embedded in the code (or a long string).
Re: Intermediate Vim tips
#37I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.
Most people store their dot files (including their vim config) in a git repo and just check out a copy on any machine they use. That's what I do (git+stow). I can be up and running on a new system in just a few seconds.
Does anybody know a saner way of doing this cross-platform? I've resorted to doing platform checks in my .bashrc and don't get me started on the OSX / Linux differences in .platform, .bash_platform, and .bashrc sourcing.
And when I tried termux on Android, oh dear lord. The whole thing breaks because of permissions issues. Had that issue on WSL too.
Re: Intermediate Vim tips
#38I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.
Just chiming in real fast that you can use ssh to edit files on remote systems even if they don't have emacs themselves via /user@host:~/filename.txt
So I also can use emacs almost anywhere. (I still advocate users and admins at least be functional in vi/vim regardless). Also don't forget GNU Nano isn't out of the game either as a small almost everywhere easy to use editor.
Re: Intermediate Vim tips
#39I’m probably the minority here but I don’t like to customize my Vim too much. 1 - it takes time. 2 - half the reason I like Vim is because I can use it anywhere. If I’m so used to a highly customized setup, then I am going to feel out of place when I log on somewhere else.
It depends what you use Vim for. If Vim is your only code editor, it’s crazy that you’d leave tons of productivity enhancements on the table because you want that standardized, bottom-of-the-barrel experience. Nice things are nice! I have tons of customizations in my Vim, and have very little trouble using vi or vanilla Vim when I log into production machines. It is frustrating to not have my magic this and that, but…
I wish I could upvote your comment many times. I wish the parent comment pointed out what use case they have for Vim, as this really dictates the "right" approach.
I wrote about this previously in the context of Vim vs Emacs, though it's similar to customized vimrc/plugins vs vanilla vimrc:
"One can reduce part of the [editor] debate down to a single question: how fully featured do you want your text editor out of the box? If you’re a DevOps engineer who spins up new environments constantly you’ll have different ideas about the best choice compared to a full stack engineer working in a single development environment that can be painstakingly setup. For the DevOps engineer, a light text editor that is installed by default is likely ideal, while for a developer with a single computer, a full-featured IDE (auto-completion, plug-ins, custom keys) is worth the high setup cost."
Re: Intermediate Vim tips
#40Earlier quoted context omitted.
Most people store their dot files (including their vim config) in a git repo and just check out a copy on any machine they use. That's what I do (git+stow). I can be up and running on a new system in just a few seconds.
Does anybody know a saner way of doing this cross-platform? I've resorted to doing platform checks in my .bashrc and don't get me started on the OSX / Linux differences in .platform, .bash_platform, and .bashrc sourcing. And when I tried termux on Android, oh dear lord. The whole thing breaks because of permissions issues. Had that issue on WSL too.
https://github.com/007/dotfiles
Lowest-common-denominator for linux and mac, mostly just "make it work if you notice it's broken". I have one file that's bash magic, and link it to everywhere it might be needed - bashrc, bash profile, etc. It's kind of monolithic, not great but at least 100% consistent for what ends up where, and avoids sourcing external stuff or requiring N different files to work. You'll see some of your pain in the repo history, change X to Y to make it osx or *nix compatible based on whichever is my primary platform.
Same goes for vim, just absolute basics for vimrc and a few very portable plugins and niceties hardwired. No package manager, just a bare directory.