My (Neo)Vim workflow | Hacker News Reader

My (Neo)Vim workflow

seniormars.com

125 pointsHadi754672 comments

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.

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

I've used oil/vinegar for a decade or more, I'd be entirely lost without -

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.

I just got around to trying :Texplore -- had no idea this existed, cool find.

Tossing up the idea whether to switch to Texplore, but you know if it aint broke...

Edit: Switched to :Texplore and also have \v bound to :Vexplore -- very handy.

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.

oh that's great -- i think i got it working with the following config:

  local builtin = require("telescope.builtin")
  local utils = require("telescope.utils")

  vim.keymap.set("n", "<leader>fa", function()
    builtin.find_files({ cwd = utils.buffer_dir() })
  end, { desc = "[F]ind [A]round currently open buffer" })

This is what I do to include the depth restriction

  require("telescope.builtin").find_files({
    cwd = buffer_directory(),
    prompt_title = "Find Around",
    find_command = vim.list_extend(vim.list_slice(default_find_command), {"-d2"}),
  })

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

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.

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.

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.

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.

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.

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.

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.

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.

use `vim.lsp.buf.rename` to rename using lsp. for example i use `vim.keymap.set("n", "<leader>rn", vim.lsp.buf.rename, opts)` to rename.

Thanks for the pointer!

try something like:

    vim.keymap.set('n', 'gr', function()
      local clients = vim.lsp.get_clients({ bufnr = 0 })
      for _, client in ipairs(clients) do
        if client.server_capabilities.renameProvider then
          vim.lsp.buf.rename()
          return
        end
      end
    end)

require('lspconfig')['tsserver'].setup{ on_attach = on_attach, ... }

local on_attach = function(client, bufnr) vim.keymap.set('n', '<leader>rn', vim.lsp.buf.rename, bufopts) end

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.

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

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.

+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.

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

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.

Yes of course. But wrt trust, it's vital for the specification! If the tests are good enough, the implementation is an implementation detail!

Well my point was that if you're starting off by writing tests, AI assistance is low-risk: the test code should be simple and concise enough to review very quickly. So you're not blindly trusting.

Tests also tend to have a repetitive and clearly defined structure, an environment that AI thrives in.

(Also, devs usually find writing tests boring, while AI never gets bored.)

And once your tests are in place, if desired you can then get AI to write the actual code too.

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.

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.

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.

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

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.

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

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.

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

I agree-- though I've been downvoted for the comment. I guess Jia Tan is a user here ;p

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

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

Same. I want to say junegunn's vim-plug started this revolution. I'm thankful for all the prolific vim plugin developers. They've really made my day to day more pleasant.

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

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.

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.

The vimscript implementation doesn't have many of the innovations of modern scripting languages. No JIT, pretenuring, inline caching, etc.

All your "one OOM away from VSCode" scripts run in a script language that is in the slowest category among all programming languages: interpreted languages.

There are probably millions of dollars invested in making scripting languages like JavaScript faster, but that's not the same case for vimscript. Same applies to other languages behind IDEs such as Java. So that intuition is not true.

With hardware accelerated widget toolkits, the TUI advantage is not necessarily true either.

Yeah, I'm not arguing whether that's right or wrong.

It just doesn't matter. Vim is objectively faster. I don't care how many millions of dollars or pl optimizations my editor has. I care how quickly it works.

Most nvim plugins are written in lua.

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.

We can all agree that the UNIX philosophy is powerful. Having a uniform interoperability mechanism (e.g.: stdin/stdout/stderr, exit codes) helps integrate different tools easily. I use shell commands to get things done often.

But that doesn't necessarily negate what I said: having a complete toolchain with a complete set of capabilities is the end goal. How you achieve that is means towards an end. If you achieved it with a TUI editor, good.

But there's a subculture in the TUI editor world where the end goal is often the prestige of being a TUI editor user rather than how capable the tooling makes you. And the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects, because even though you could integrate LSP, a linter, etc... a lot of them don't.

With respect to when vim was invented, you have a supercomputer now. You may be solving a performance problem you don't have.

If editing with a minimal experience is a deep part of who you are, yet you are not going to pay for the cost of detecting and correcting preventable problems which can cost the company thousands to millions of dollars... maybe you are not acting in the best interest of your development org, your colleagues, your career or your family even. What do we call a person that exhibits that behavior?

> the situation in the wild is that most of these TUI users have a sub-optimal development experience that causes them to push more defects

What an amazing pile of unsubstantiated horsefeathers!

> because even though you could integrate LSP, a linter, etc... a lot of them don't.

I think you overestimate the amount of work needed to get these things working… With Vim, for example, you can install a single plugin “ALE”, and it will autodetect and integrate every known LSP server, linter, and formatter that is in $PATH. For Emacs, you won’t even need a plug-in: “Eglot” is included in Emacs itself, and autodetects and integrates LSP servers in $PATH when you turn it on. Turning it on can be done by clicking a discoverable menu bar item.

> yet you are not going to pay for the cost of detecting and correcting preventable problems which can cost the company thousands to millions of dollars... maybe you are not acting in the best interest of your development org, your colleagues, your career or your family even

This is a bit of a stretch, isn’t it? If a single dev turning off their linter can cause millions of dollars worth of problems and bankrupt your family, then your org has deeper problems.

This has always been the problem. It takes one faulty line of code to bring down the entire planet and you know it.

My position would still be that:

- If you’re working on critical code where one wrong line can bring down the planet, it is your organization’s responsibility to adapt. This means thorough testing before you roll it out to production, code review, etc.

- If you’re convinced that linting, testing, etc. is essential to prevent calamities, it shouldn’t be up to individual developers IDE choices to use these. Then it’s again up to your org to centralize and mandate those tools, e.g. by adding autoformattets, linters, and test coverage checks to their Git precommit and code review. This is an organizational issue.

- If we take a step back from these calamities, and claim that an IDE just makes people more efficient… Isn’t it again up to your org to promote and pay the efficient developers more, and gradually the top positions will be filled with IDE users and that becomes the company culture if your hypothesis is right?

In any case, I strongly disagree with your angle that not using an IDE is “irresponsible”. I have my reasons for sticking with a terminal-based workflow, but respect and understand why other people might find an IDE better.

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.

You can map most actions in an IDE to a key combination.

And IDEs have integrated terminal panes as well.

Never said it can't be good in an IDE. But there is something that draws people to vim, which isn't just the cool factor. IDEs often even have vim modes but vim itself is a nicer editor.

Same way an IDE is a nicer debugger, linter, profiler, test run platform...

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.

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

Still better than the circular arguments like vim is faster because vim is faster.

It’a not better, they are both worse. The best editor is the one you know. I also know lots of people who use IDEs and don’t use most of their features.

If we have a test or a linter that prevents a problem, that runs in a couple of milliseconds, and you didn't run it because you are too cool to run it, then we are no longer talking about subjective preferences about tools. We are talking about responsibility.

If your code caused data loss on production because you are LARPing about being a hotshot instead of adopting the processes that keep the code running I don't care how fast your editor is.

Lol, you're exactly who I'm complaining about. I do agree with you: I also dislike people who don't learn their tools and don't do the things you're talking about. But just because you're using an IDE doesn't mean you're going to use all of its features. Conversely, if you're going to use a text editor, you absolutely have to ensure you have that stuff.

Does your team have required code reviews? This might help reduce production incidents

- sent from my terminal

Checks running on continuous integration is the mitigation for not having used a linter during development in this case.

The linter feedback would take longer to get back to the developer though, increasing the "cost of change".

What does the choice of editor have to do with whether you run tests?

Reply on news.ycombinator.com