My (Neo)Vim workflow

[commandersaki]

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.

[Zizizizz]

I imagine you aren't going to install a plugin for this but oil.nvim is really great for this as you can also use it to edit your directory listing like a buffer to easily create/rename and delete files and directories.

https://github.com/stevearc/oil.nvim

[JoshTriplett]

This is really handy, thank you!

There's a shorthand :Texplore which does the same thing as your :tabedit invocation. Also, if you change it to

    ':Texplore */%:t'

, it'll open the directory of the current file and put the cursor on the current file.

I've added this to my .vimrc:

    noremap <C-b> <Cmd>Explore */%:t<CR>

This binds Ctrl-b to browse in the directory of the current file.

[kzrdude]

I've got a lot of shortcuts set up for telescope (fuzzy finder ui in neovim). One of them is leader fa for "find around" which limits the file list to current directory and the next level down (only). It's quite useful in the same scenario.

The regular fuzzy finder is unfortunately useless in the home directory (too many files), with this limit, it's useful.

[pawelduda]

I have the same, except via ranger.vim, which integrates it with said program - it's an excellent pairing

[joshcsimmons]

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.

[bdjsiqoocwk]

I went the opposite direction, from nvim to vscode, and I've never had to "configure" anything again.

Look some people just like tinkering. To me a text editor is a tool, not a hobby or a love affair. You see people going "I've added 100 plugins and it's great now" and the same people later "I've got rid of 100 pluggins and it's great now". The mean time I'm getting stuff done.

[goosejuice]

In my opinion, neovim is productive out of the box. I'd recommend grabbing lazyvim if one wants something fancier and customize it from there if needed.

I've used vim as primary editor for about a decade. Just started using Cursor (vscode fork) for last few months and still much prefer nvim - but copilot++ is a game changer so I deal with it. I do use the vscode-neovim extension.

The biggest thing I miss is a terminal based workflow. I find GUI editors unnatural. Much prefer my editor in the terminal.

[chasinglogic]

I prefer modal editing. It feels the best to me, but that could be because I learned it.

I had to learn vim back when I was a basic system administrator so when it came time to start doing real coding it was an obvious choice. I also prefer properly open source software, and if possible, non-corporate backed. So it checks all my boxes especially now that I'm not "missing" anything from VSCode.

When people ask me though I recommend VSCode to most normies, I don't think vim is worth it nowadays.

[Ezhik]

I love editing in Vim, but I definitely want nice things and IDE features. At this point I've had a better time getting Vim editing into VS Code than getting VS Code IDE features into Vim.

[MistaGobo]

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.

[goosejuice]

I agree, but not all LSPs support this for what it's worth. For local variables it's not really a big deal, for global references I just find all references and change in each buffer.

[shmerl]

How do you rename it with LSP?

For now I got to setting up LSP configs and servers for a few languages but didn't get into using it yet besides getting extra syntax highlighting.

[zingerlio]

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.

[commandersaki]

Yeah I switched from old vimrc style to Kickstart, it's been pretty great. The only opinionated bit that I dislike is enabling breakindent.

[MegaDeKay]

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.

[glennericksen]

+1 to Typecraft for reworking your Neovim setup. As a longtime Vim user, I adopted Neovim with my Vim .vimrc in order to use Copilot. With Typecrafts guidance, I switched to Lua config, and really happy with where I ended up. Haven’t touched VSCode in months.

[tasuki]

> 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?

[sevg]

I think it's easier to review test cases as they tend to have less code, less complex logic, and less interaction with other code.

[threePointFive]

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.

[intothemild]

Very true. Also don't forget nvim-lspconfig.

Finally the tooling around LSPs has got better, but I feel it needs to go further. Modern languages like Go and Rust have excellent LSPs, but java. It's not great. I know java is just an absolute mess when it comes to tooling, but I wish there was some standardisation here.

[teo_zero]

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?

[parentheses]

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.

[__s]

The "best of both worlds" solution if one wants to stay on neovim is coc-nvim

Good to see neovim integration progressing. When I stopped using vscode years ago neovim integration was limited to ex mode in vsvim

[shmerl]

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

[roland35]

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.

[alentred]

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.

[bbkane]

I recently did something similar: https://github.com/bbkane/dotfiles/tree/master/nvim-03-lazy

[Squeeeez]

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

Is this your own? Or just one you liked?

[llmblockchain]

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.

[troad]

You are definitely not the only one.

It's wild to me the extent to which some devs just sorta volunteer for RCE.

And often, for the most superficial of reasons? "Oooh, this plugin adds emoji error messages!" one hundred and forty-three black-box dependencies from anonymous github accounts later...

[manbash]

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.

[bionsystem]

I hate when that happens, a lot of searches around the neovim ecosystem ends up with various replies that assume 96 layers of knowledge even before understanding what the solution is about.

[pacomerh]

after years of using my custom neovim config I honestly just transitioned to lazyvim and it removed so much maintenance time, I'm happy with it

[xigoi]

lazy.nvim is a plugin manager. LazyVim is a Neovim configuration. Don’t confuse the two.

[shmerl]

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

[throw156754228]

Vim life.

[29athrowaway]

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.

[drawnwren]

This reads like the sort of academic engineering that I hate working around. You ask great questions for research, but the truth of the matter is quite simple.

You can just open both editors next to each other and ask how they are. For me, it's trivial to see that vim is at least an oom faster than VSCode. I don't need to profile or show test coverage. I can just use it and it works. Even if they were about the same speed, the less-than-perfect vim mode implementation always takes too much time out of my editing flow.

Occasionally, an ide will have such a great curated experience that I'll use it for something specific -- but the general case is a no contest for me.

[eikenberry]

The primary mistaken assumption you've made (though some TUI users also suffer this) is that the TUI is the integration point (the IDE) and that is not the case. Text editors, like Neovim, are are only the editor part or component of the IDE, your terminal shell environment. The shell has had decades to refine its place as the integration point for development. It works very well and keeps closer to the classic, do one thing and do it well, mentality. This has many benefits that don't translate well to GUI IDEs as they just can't match the flexibility and maturity of the shell ecosystem.

[vincentkriek]

I usually doubt about this, am I missing out on useful tools because I like my terminal based environment. Editing is much better when you have tools that are keyboard first, I think everyone agrees about that.

My conclusion now about an integrated environment (like an IDE) versus a more handbuilt (like vim) is that a handbuilt one requires the dev to know it's tools. With an IDE you are seduced to trust the magic black box, that the box will help you. This makes it that when stuff goes different then expected (usually user error), you are lost.

With a more custom environment you are pushed to learn your tools. And while this is not a given, I like this approach more. I might miss some fancy new tools, but the tools I do use, I *know*. This could be done with an IDE but is more forced in a terminal based flow.

[c-tb]

the problem with that mindset though, is if you don't want several of these features. or you use a variety of languages and tools where the common interface is the terminal. i work professionally in Kotlin so i would never use vim over IDEA over that. but getting all sorts of other languages working in something as bulky as IDEA is a huge pain and not generally worth it.

for the longest time (pre-LSP), my non-kotlin dev experience was just vim-polyglot and running watch - build in a :vsp and it gets you far.

[sodapopcan]

> 99.9% of the time the answer will be "Well, I haven't set that up yet...but look at this multiple cursor trick!"

Ah yes, the classic "takedown" with the invented statistic about what people "probably" haven't done while "probably" focusing on something less important. Bravo.

Side note: most Vimmers don't use multiple cursors... it's 99.9% of them, I believe!