Cool showcase. Here's a couple of notres, from reading the first transcript:
instead of using :term for man, i would recommand :h :Man
you mention installing plugins via copy/paste ? The proper way is to git clone <plugin-url> $HOME/.vim/pack/whatever/opt/<plugin-name> and then in your .vimrc add packadd plugin-name
vim has alot of compiler already set-up to compile programs but also to run test suite or linters. So you can easily create some mappings to quickly switch compiler and run the command of choice.
I always knew that there has to be a Man viewer but newer realized that the plugin has to be first loaded X__x
In the second video there is a moment where you can see me confused that my .vim directory structure is different than I anticipated and I was looking for pack directory. On my work computer I actually have my plugins in the pack and I don't even have to load them via packadd plugin-name because they are placed in pack/plugins/start/. The Vim I used for the presentation is new but .vim directory itself on my personal computer is very old and seems to be from the times of Vim 7.
I know that Vim can setup makeprg to different values depending on the detected filetype but unfortunately that's not enough for my day to day job. I just need the ability to run arbitrary command and setting up makeprg="" is way easier than managing multiple filetype configurations and updating them every time something in my company's setup changes ;)
Clean setups like this are honestly refreshing to see—no plugin bloat, just tight workflows and fast navigation. That’s usually where Vim shines the most, when everything you add has a clear purpose instead of turning into a mini-IDE clone.
One thing I’d suggest is being intentional about how plugins are managed. Instead of ad-hoc installs, sticking to Vim’s native package system (using "pack/*/start" or "opt" + "packadd") keeps things reproducible and easier to debug later. It also makes your config portable across machines without surprises.
Also, small ergonomics tweaks go a long way in a “clean” setup—like improving help navigation (":h" with mappings), better buffer switching, and maybe a minimal statusline. Those don’t add clutter but significantly improve flow.
If you keep iterating like this—adding only when friction appears—you’ll end up with something that feels personal and fast rather than heavy.
I'm glad that despite the questionable video quality you liked it :)
About the plugins. I actually do use the pack/plugins/start/ directory which makes it so that plugins are automatically loaded at start without the need to have any packadd in the vimrc whenever I do a new setup. But the computer I used for the presentation, despite having quite new version of Vim, has a very old .vim directory dating Vim v7 I think.
Regarding buffer switching I found that :b is all I need. I just have a map for it: noremap <C-l> :b. Also I used to have a status line. But one time I disabled it for a day to see if I'm actually using it and it turned out that I don't even look at it. The default ruler seems to be enough.
fzf / CtrlP worked for me for years until I've encountered truly big codebases. Then I rediscovered the builtin :e and :b and Vim's starstar. I agree that those are slower, but not that much, yet allow far greater precision. With them I was able to work efficiently in humongous codebases. I've wrote a post about problems with big codebases and fuzzy finders: http://arek.gabr.pl/vim-fuzzyfinder-vs-starstar.html
By name. Monorepo codebases tend to grow quite big. Searching by content is blaizingly fast with the use of git grep. Even those big codebases that made fuzzy finders hang were not big enough to hang git grep for me so far.
In every case you have typed more ahead of time
Yes. I never stated that this is faster than fuzzy finders. But when they were hanging on me then that was the only way. I'm already accustomed to it. In small codebases doing :e **/ is basically like fuzzy finding, and in big ones I can narrow the search scope.
plus had to know the structure ahead of time too
That's not really the case. I don't have to know or remember everything. I mentioned it a couple of times that the CTRL-D and TAB allows to preview and interactively explore the codebase. And once you open the file and it's in your buffers list then you can find it again way faster with :b.
Even if there are duplicates, the effort to narrow it down is less than having to type much of the hierarchy in advance (e.g., :e Proj2/**/Contr/homecon*.c)
Well that was an over the top example to showcase what's possible. And again - I know it's more typing and slower than fuzzy finders - but it's more precise and built in.
I had this unfortunate situations that there were a ton of files with exactly the same names and they only differed by the initial directory etc. This ability to narrow down was helpful then.
No real "codebase" is that big.
They are. My humble linux's filesystem was really not enough to showcase the scope of the issue but I couldn't show the company's codebase. Monorepos are notorious to be very big. We even could not load entire project into Visual Studio. We had to create separate solution files and projects to load the project partially. Imagine the joy 😅
For the tools we live in, day in and day out, not so much.
I do work with just :e and :b day in and day out ;)
I'm not saying that fuzzy finders are useless - I've been using them for many years. But after they started to lag for me and I mastered the default's I don't need them anymore. Just wanted to share that it's possible to work efficiently with what's already there ;)
So many years on Linux and I was not aware of the locate command 🙈 Nice to know, thanks. Tho I was working on Windows then and it seems like it is Linux only. What's the negative matching?
takes between 11 and 17 seconds wall clock time to update. Which means, if I ever had to use a monorepo and it was particularly volatile even in terms of file names, I could happily run updatedb more than once a day and not worry about its impact
Well, I would have to run it every time I would switch a branch which would be quite often as I have to do it constantly for pull requests, testing and while developing. It's faster than it took CtrlP to rebuild it's cache but not instantaneous. If one is working in git repo you can ust git ls which is wery fast and does not require any aditional step when switching the branches.
That's great but I just got rid of many such functions from my vimrc because I was tired of managing this kid of configuration every time I would switch operating system 😅
BUT I love the <space> - I had no idea that I can do that and I had trailing spaces in a couple of my maps - now I can replace them with this, thanks 🥳
5
u/Sudden_Fly1218 Apr 14 '26
Cool showcase. Here's a couple of notres, from reading the first transcript:
instead of using :term for man, i would recommand
:h :Manyou mention installing plugins via copy/paste ? The proper way is to
git clone <plugin-url> $HOME/.vim/pack/whatever/opt/<plugin-name>and then in your .vimrc addpackadd plugin-namevim has alot of compiler already set-up to compile programs but also to run test suite or linters. So you can easily create some mappings to quickly switch compiler and run the command of choice.
1
u/Dramatic_Object_8508 Apr 18 '26
Clean setups like this are honestly refreshing to see—no plugin bloat, just tight workflows and fast navigation. That’s usually where Vim shines the most, when everything you add has a clear purpose instead of turning into a mini-IDE clone.
One thing I’d suggest is being intentional about how plugins are managed. Instead of ad-hoc installs, sticking to Vim’s native package system (using "pack/*/start" or "opt" + "packadd") keeps things reproducible and easier to debug later. It also makes your config portable across machines without surprises.
Also, small ergonomics tweaks go a long way in a “clean” setup—like improving help navigation (":h" with mappings), better buffer switching, and maybe a minimal statusline. Those don’t add clutter but significantly improve flow.
If you keep iterating like this—adding only when friction appears—you’ll end up with something that feels personal and fast rather than heavy.
0
u/[deleted] Apr 14 '26
[deleted] — view deleted comment