My (Neo)Vim workflow

Probably my most useful (neo)vim productivity tip is:

    vim.keymap.set('n', '\\.', ':tabedit %:p:h<CR>')

My leader is \, so when I press \. it will open netrw in a new tab in the directory containing the file whose buffer I was just editing. I use this all the time when I need to navigate source trees as I don't care much for fuzzy file finders. Credit to -romainl- who taught me about %:p:h.

This is so interesting and complex! I'm relatively new to Neovim - I've tried to learn a couple of times but it finally "took" a few months ago.

Genuine question for the author - have you configured Vim this way in order to be more productive or because you enjoy customizing it? I don't mean for that to be antagonistic, people build and customize muscle cars to show off even though they're slower than Teslas.

It's wild to see the community around recreating VSCode in the terminal (Astro Nvim, NvChad, etc.) I guess if I had to customize Vim so much for it to be a usable solution I'd just go back to using VSCode. After all, keyboard-action-speed is pretty much never the bottleneck when coding, thinking is.

Renaming variables should be done using an LSP, not find/replace.

I'd try to avoid using your mouse altogether; because it's faster and for me, avoids neck/shoulder strain.

Also, I'd recommend oil.nvim which is great for doing file exploration and manipulating. You can edit/move filenames naturally in a vim buffer, and then save to apply changes.

For casual users like me, I find Kickstart (https://github.com/nvim-lua/kickstart.nvim) a good and sensible default that's not too opinionated.

Similar to this, Typecraft on YouTube has an excellent "Neovim for Newbs" course that is really great. He starts with vanilla Neovim and basically turns it into an IDE. He uses some of the same plugins as this article does, but also goes into depth for "the new hotness" (as this article calls it). What is quite nice is he breaks the different functions up into separate lua scripts rather than putting it all into one big config file.

https://www.youtube.com/watch?v=zHTeCSVAFNY&list=PLsz00TDipI...

There is a separate playlist that shows how to smoothly integrate Tmux with Nvim so you can do things like Ctrl H/J/K/L between Neovim splits and Tmux splits seamlessly.

> First, I use copilot to complete test cases and boilercode – I don’t trust it for logic

Very interesting! I want to write the test cases myself. When copilot writes some code that passes my tests, I think I can trust it.

If you don't even trust copilot to write your logic, how can you trust it to write the specification for how the logic should behave?

My biggest gripe with the ecosystem right now is complete lack of any consistency around language servers, which seems to come from the fact that many were written assuming they would only ever be a VSCode plugin (ie. typescript-language-server). The author is using coc.nvim which appears to be a VSCode compatibility layer for nvim to deal with this. I've primarily used Mason.nvim just to manage my LSP installs. I'd really love for LSP (and DAP) tooling to make its way into distribution repos, but I'm not sure what needs to change to make that a reality.

I'm torn about ignorecase/smartcase: for interactive searches it's great, but there's no way to exclude it when invoking gd, gD, *, :tags, etc. (at least in Vim, not sure about Neovim).

I'm thinking of leaving ignorecase off and mapping / to /\c so that it's clearly only applied to interactive searches, and can be disabled with just 2 backspace presses.

What's your take?

I used to be a very hardcore neovim user until I got sick of manually configuring LSP plugins. In VS Code, things typically work much better. So, I opted to have the best of both with vscode-neovim. There are small glitches from time to time but those are worth the convenience of having the better (for me) interface.

I noticed the video has some neat split resizing using keys. Looking around, I came up with this if anyone needs:

    -- Ctrl + arrows resizing splits
    vim.keymap.set('n', '<C-Up>', '<Cmd>resize +1<CR>') -- increase window size vertically
    vim.keymap.set('n', '<C-Down>', '<Cmd>resize -1<CR>') -- decrease window size vertically
    vim.keymap.set('n', '<C-Right>', '<Cmd>vertical resize +1<CR>') -- increase window size horizontally 
    vim.keymap.set('n', '<C-Left>', '<Cmd>vertical resize -1<CR>') -- decrease window size horizontally

Lazyvim is so good now I basically just install that and am good to go. I add a few themes and have a handful of custom commands (JK as escape, jkl as save) but other than that it is ready to rock.

Mason makes it very easy to install additional language support.

I, for one, have recently refactored my NeoVim config in the exact opposite direction: now using mostly default nvim settings, dropped lots of plugins, etc. Feels great really. Quite honestly I was simply tired of maintaining my old configs. It ended up to be easier to (re)learn some default key mappings instead.

This, however, only works with software with good backward compatibility. Here is to nvim to be that kind of software.

Well, there goes the evening. Merging configs trying out stuff.

Is this your own? Or just one you liked?

Am I the only one that sees so many third party dependencies and gets nervous? All it takes is one bad plugin or maintainer change for your entire system to be owned.

The article should at least preface with some explanation about lazyvim.

Some snippets simply have comments like "I use lazy.nvim to load plugins" and that's it.

I'd recommend fzf.lua for search, it's very cool.

Vim life.

I believe that your toolchain should be doing work for you, not the other way around.

A toolchain should also be discoverable and well documented.

A toolchain should also be complete:

- editing

- syntax highlighting

- syntax validation

- linting

- building

- testing

- profiling

- debugging

- searching

- documentation

- version control

Optionally also

- deploy

- inspect logs

You can do a lot of work and testing to these working correctly, install a "distribution", or you can simply use an IDE.

You can argue that you can do all these things with plugins, but plugins do not follow unified guidelines and the result can be an inconsistent experience like the Dwarf Fortress menus.

A TUI editor with many plugins installed isn't necessarily faster than an IDE. Languages like vimscript are interpreted, not compiled. And many implementations not always take advantage of multi-threading capabilities.

Among the distribution of TUI editor users, only a small subset of users can get their toolchain to be ergonomic, complete and work correctly. The rest just have a minimal experience that just gives them more work to do and that places a quality handicap on them.

How do you read profiler output in your TUI editor? or show test coverage? or run a specific test case in a test file and get a test report? 99.9% of the time the answer will be "Well, I haven't set that up yet...but look at this multiple cursor trick!". And the median skill level TUI editor user often hasn't even set up a linter or something like LSP integration.

What TUIs are excellent for, in my opinion, is to encourage an immersive experience that's distraction free. But now many IDEs have distraction free modes.

They can be good for customization (which can even result in customizations that make your work more difficult), although IDEs have SDKs that are not hard to use and many plugins are open source.

TUI editors are also more compatible with working on remote hosts.

Now, through customizations you could in theory create a universally superior development experience compared to what IDEs offer, but that is yet to be seen. Only in some aspects TUI plugins have achieved this level of excellence in specific areas, like Magit for emacs.