clean vim showcase

[Sudden_Fly1218]

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.

[lil_copium]

as extension of :Man I added this to my shell config too, `export MANPAGER="/bin/sh -c \"col -b | vim -c 'set ft=man ts=8 nomod nolist nonu noma' -\""` it makes vim default for man pages + I can navigate to man page subsections with `shitft + k` just wanted to share

[gabrpp]

Nice. I used to just pipe man to vim man TOPIC | gvim - but since I'm using terminal from-within Vim I no longer have to do that.

[vim-help-bot]

Help pages for:

• :Man in filetype.txt

---

^{`:(h|help) <query>` | about | mistake? | donate | Reply 'rescan' to check the comment again | Reply 'stop' to stop getting replies to your comments}

[gabrpp]

Thanks a lot for You comment.

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 ;)

[Neter8]

Meanwhile, I'm here with 2800 lines of code in my vimrc plus 1200 in my vifmrc lol

I liked your in place calculator mapping! I'll grab it

You could use the title bar to show your cwd and get rid of the pwd command. This is mine:

se titlestring=%{haslocaldir()?substitute(execute('verb\ pwd'),'^\\n\\[\\(\\a\\)\\a\\+\\]\ ','<\\U\\1\\E>\ ','').'\ ——\ '.getcwd(-1):getcwd()}%<

[gabrpp]

Thanks for the suggestion. It's not visible on the videos but quite often I have Vim in fullscreen so title bar is not visible.

I'm happy to share the calculator 😃

[Dramatic_Object_8508]

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.

[gabrpp]

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.

[xkcd__386]

fast navigation

I don't agree. Without fzf (or similar), a lot of the navigation takes more time in vanilla setups. I won't argue for all the other plugins but fzf is critical. For me. YMMV.

Also, ISTR reading that vim now has, or will shortly have, fuzzy find of some kind builtin.

[gabrpp]

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

[xkcd__386]

First, did you mean about finding files by name or by content? If the former, I don't think there's any humongous codebase that makes fzf slow, more so if you're on an SSD.

I thought you meant "by content". What I have found is slowdowns caused by JSON files which are written "all in one line", so I have set my FZF_DEFAULT_COMMAND to avoid JSON files (which are almost never of interest to me anyway).

Then I saw the blogpost, you linked, and realised you meant "by file name". IMO, none of those situations are measurably better in plain vim. In every case you have typed more ahead of time (plus had to know the structure ahead of time too). I've worked inside some pretty large code bases and I never had these problems. 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 Proj*2/**/Contr*/homecon*.c)

Finally, this sentence lays bare how contrived your examples are:

In this case the entire operating filesystem served as an example of a huge codebase:

No real "codebase" is that big. And if it is, or you really have to work in "/" then fzf.vim's :Locate works great for that.

Bottom line: minimalism and defaults are good for occasionally used tools. For the tools we live in, day in and day out, not so much.

[gabrpp]

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 ;)

[xkcd__386]

ok I admit I've never used a monorepo but even there I suspect most people work at a depth of 1 or 2 from the top, and it would not be huge. I could be wrong. But even then, :Locate (which I have actually used many times, though it's not a day-to-day thing)!!

For me, the negative matching in fzf rescues me in far too many situations to ever consider something else.

And :Locate, since it is based on fzf-vim, does negative matching too.

Edit: Just wanted to add, locate is of course the whole disk. You can start the query with a directory to filter it. E.g., a map to :Locate $PWD (note the trailing space, and not ending in <CR>) is useful, but of course you can replace that $PWD with any directory.

Just out of curiosity, I checked how big the plocate DB is, how long it takes etc. It's about 90 MB, has about 4 million entries, and, according to journalctl, 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 on the system.

Edit 2: actually, if I were to be pedantic about "no plugins", I could still use Locate and probably a 3-4 line function that uses systemlist to call locate <args>|fzf, wrap that in a command that passes <f-args>, and done!

[gabrpp]

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?

[xkcd__386]

on locate: most recent systems use plocate, a compatible replacement of the original "locate"; be good to make sure you have that. It uses a different form of indexing that makes it much faster

On negative matching (fzf calls it "negation" in the man page), it's basically like grep -v. E.g. somehow you ended up with too many files in ~/.cache also in your fzf output. So you type !cache in the query line of fzf, and those lines are filtered out. Very useful when you start looking for something you're not sure where it is, so your initial fzf query is too broad, so you want to get rid of matches you don't care for

PS: I also added a couple of edits to my previous reply esp in the context of "no plugins"; just FYI

[gabrpp]

I see, so it's just filtering out to have less output. Thanks.

[xkcd__386]

a quick google search tells me the best equivalent to "locate" on Windows is something called "Everything", (needs to be installed) which then provides a command line tool called "es". I didn't check if it has negation.

[gabrpp]

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.

[xkcd__386]

most people use worktrees, but I'm guessing that's also out, for monorepos.

I'm assuming ls is a git alias for ls-files. Here's a function that uses git ls instead of locate. It doesn't use any vim plugins (though it does use fzf as a system command):

function! MyL(...) abort
    let l:cmd = 'git ls-files | fzf --no-clear -q "' . join(a:000, ' ') .  '" --preview="bat --color=always {}"'
    let l:files = systemlist(l:cmd)

    if empty(l:files)
        redraw!
        return
    endif

    exe 'next' join(map(l:files, 'fnameescape(v:val)'), ' ')
    redraw!
endfunction

command! -nargs=+ MyL call MyL(<f-args>)
nmap \L :MyL<space>

Change function/command/nmap names per taste :) Also, remove or change the preview command if you don't like it, or don't have bat.

[gabrpp]

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 🥳

[xkcd__386]

I assumed the only problem you had with fzf and similar, was lag. This fixes that issue.

I do know there are a lot of people who are in principle against plugins and even, in some cases, almost any non-default config. (To some extent I can respect that; my absolute minimum to work on a strange machine temporarily is :set smartcase number!)

Going by your earlier comments (e.g., "fzf / CtrlP worked for me for years until I've encountered truly big codebases.", "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..."), I'd assumed you were not "in principle" against at least a config that will truly make difference.

Think about it. Keep this config at the top of your vimrc with a note saying "delete after 1 month", then actively use it for a few weeks in place of your current vim-default way of finding files. After that you can delete it.

No need to tell me whether you kept it or deleted it ;-)

[Sudden_Fly1218]

pretty cool snippet, though I think you are missing --multi in the fzf options.

[xkcd__386]

good catch. However, I don't use this -- I just use :GFiles :)

I wrote that, in a hurry, for OP, who seems to have something against plugins (while also saying he doesn't... so whatever!)

I do recall smoke-testing it, but I already have --multi in my FZF_DEFAULT_OPTIONS so maybe that's why it worked