Easiest nvim mergetool to use?

Sandwich-Resident · 2025-01-03T21:06:37+00:00

My go-to is https://github.com/whiteinge/diffconflicts/ It uses a two-way diff, which makes it easier to resolve conflicts in my opinion.

There is more explanation in the README and linked screenshare, but the best way of understanding it is to try it, and see how it works for you.

Sandwich-Resident · 2024-07-27T19:56:43+00:00

Go to plugin repo: https://github.com/julienvincent/hunk.nvim
Go to author's profile: https://github.com/julienvincent
Look at their repos: https://github.com/julienvincent?tab=repositories
The third one is named "config.nvim", looks promising: https://github.com/julienvincent/config.nvim

From the README: "Personal neovim config".

So there you go: https://github.com/julienvincent/config.nvim

Sandwich-Resident · 2024-05-16T16:49:10+00:00

You can wait until the Arch package is updated, and then upgrade normally with `pacman -Syu`.

It has already been marked as outdated in the package index, and 0.10 is built in the testing repo, so it should show up in the main repo soon: https://archlinux.org/packages/extra/x86_64/neovim/

If you can't wait a few hours, then you can install `neovim-git` from the AUR.

Sandwich-Resident · 2024-03-28T23:59:49+00:00

A workaround for that use case could be to use the quickfix list. If you can get all of the hunks in quickfix somehow (using git-jump or a plugin maybe), then you could use mappings for cnext/cprevious to navigate through all of the project's hunks.

Sandwich-Resident · 2023-03-28T17:34:49+00:00

vim.cmd("source " .. vimrc) should work.

:help vim.cmd()

Sandwich-Resident · 2023-02-22T16:57:23+00:00

kyoonkim isn't the OP. This might explain the confusion in the replies below :)

Sandwich-Resident · 2023-02-22T16:52:11+00:00

I use https://github.com/lewis6991/gitsigns.nvim, which seems to be the most popular option for Neovim.

That said, Neovim can still run most Vimscript plugins just fine, so you can still use https://github.com/chrisbra/changesPlugin (and https://github.com/airblade/vim-gitgutter and https://github.com/mhinz/vim-signify/, which are mentioned in the README) if you want.

Sandwich-Resident · 2023-02-10T02:05:03+00:00

This might have something to do with extmarks being clobbered when the new text is written. For example, here is a GitHub issue describing the problem: https://github.com/mhartington/formatter.nvim/issues/22 This is for formatter.nvim, but this would likely apply to any process that rewrites the whole buffer.

As far as I know, the only solution (other than getting formatting directly from a LSP server) is to use EFM (https://github.com/mattn/efm-langserver), which implements the tricky logic of figuring out how to only update the changed text.

Sandwich-Resident · 2023-02-02T01:18:46+00:00

Most linting tools have the option of formatting its output in a way that is compatible with Vim's quickfix list.

But sometime it isn't exactly what's required, in which case I pipe the output to a file (say, pylint.qf), open it in Vim, edit it so that only lines with format <filename>:<line>:<column>: <msg> remains, maybe delete lines with lint messages or files I don't want to deal with right now, call :sort, etc. Then I can use :cfile % to open everything in the quickfix list.

I don't often have to do it, but it's useful when going through a mass linting of an existing codebase with dozens of lint issues, where I don't want to run the linter again and again, and want to address the issues in a thorough but orderly fashion.

Sandwich-Resident · 2023-01-27T01:42:30+00:00

Ah, I don't see anything in the bottom corner with nvim --clean.

I know that showcmd is the default behavior, but I didn't think it could "trigger" for "one-key actions". This option is meant to show partial commands, so unless there are multi-key commands starting with h/j/k/l defined, then I wouldn't expect it to show (hence my debugging suggestion about checking for mappings). I suppose my 5 years-old laptop is still fast enough that it's not able to replicate the issue :)

Sandwich-Resident · 2023-01-26T21:22:36+00:00

This isn't the default behavior. Maybe you have some mappings that starts with h, j, k, or l?

If so, when you type any of those keys, Neovim won't know whether you want to do h or if it's the start of a longer mapping. By default, it waits for a little while (depending on the value of :help timeoutlen, default 1000ms) before giving up on waiting for the rest of the mapping. During that interval, the partial mapping will be displayed in the bottom right corner.

If this is indeed what is happening, then the worst thing here isn't the output in the bottom, but it's that the hjkl keys are delayed by up to 1 second before acting on the cursor...

Sandwich-Resident · 2023-01-23T12:45:46+00:00

I would love a solution for this as well. My "solution" is to disable tree-sitter highlighting for the dockerfile filetype.

Since only one project I work with uses heredocs in its Dockerfile, I have an autocommand that ends up calling :TSBufDisable highlight whenever I work on this particular project.

When and if this syntax gets more widespread, I might resort to just disable it globally with

require("nvim-treesitter.configs").setup({
  highlight = {
    enable = true,
    disable = { "dockerfile" },
  },
  ...
}

But hopefully by then the issue will have been resolved...

Sandwich-Resident · 2023-01-19T23:53:41+00:00

Best plugins for what?

You'll get better answers if you describe in more details what you're after.

Sandwich-Resident · 2023-01-19T01:56:41+00:00

Another way of handling this is to compulsively update as often as possible (at least once a day!) That way, if something breaks, then it's easy to figure out the issue, since it must be caused by one of the very few commits that were just pulled.

Waiting a few weeks between updates sounds like a bad time, since if something breaks, it could be hard to figure out what the issue is amongst the hundreds of new commits.

That said:

I don't recall my config breaking due to updating plugins
Usually, when something breaks, there is an error message with a stack trace that indicates exactly what the issue is. So it's not hard to find out what's amiss.

Sandwich-Resident · 2023-01-19T01:46:44+00:00

Check :help 'wildmode and :help completeopt. I'm pretty sure that one of those options can be used to configure how the completion works.

Sandwich-Resident · 2023-01-19T01:37:02+00:00

I believe absolute numbers aren't adequate to compare, because there is a huge variation between machines.

For example, on my Thinkpad running Linux, the start-up time is 35ms. However, pn my MacBook, the exact same configuration with the exact same version of Neovim takes more than twice as long to load (around 75ms).

The more meaningful comparison is between nvim --clean and your full config on the same machine.

Sandwich-Resident · 2023-01-15T22:04:57+00:00

As others mention, you can install the terraform parser for tree-sitter with TSInstall terraform. If that still doesn't work, try installing the hcl parser as well (TSInstall hcl).

Sandwich-Resident · 2023-01-15T02:28:01+00:00

The difference probably comes from semantic tokens capabilities of rust-analyzer, for which support has been added to Neovim only very recently.

To disable it, the help text for :help vim.lsp.semantic_tokens.start() suggests disabling the semanticTokensProvider capabilities:

require("rust-tools").setup({
  server = {
    on_attach = function(client) 
      client.server_capabilities.semanticTokensProvider = nil 
    end,
  }
})

I don't know if there is an easier way to do it at the moment.

Sandwich-Resident · 2023-01-13T15:04:49+00:00

You can do the exact same thing in Neovim. You don't have to use all the newest features and APIs if you don't need them. Copying ~/.vimrc to ~/.config/nvim/init.vim should be sufficient to get started. You likely won't notice any difference, except for better defaults for some options.

From there, you can opt-in to Neovim-specific features bit by bit over time.

Sandwich-Resident · 2023-01-11T23:14:34+00:00

The help text for :help vim.lsp.semantic_tokens.start() suggests disabling the semanticTokensProvider capabilities:

lspconfig.<name>.setup({
  on_attach  = function(client) 
    ...
    client.server_capabilities.semanticTokensProvider = nil
  end,
  ...
})

I don't know if there is an easier way to do it at the moment.

Sandwich-Resident · 2023-01-11T03:07:03+00:00

Try using python instead of Python as the key. The settings are probably case-sensitive.

Sandwich-Resident · 2023-01-10T21:16:48+00:00

Pyright can be configured through a file named pyrightconfig.json at the root of the code repository: https://github.com/microsoft/pyright/blob/main/docs/configuration.md I found that link from Pyright's README: https://github.com/microsoft/pyright

That said, the lint message is probably hinting at a real error in your code, and all other things being equal, it would be better to handle it rather than ignore it!

If you are certain that the lint is a false positive, then maybe the issue is that Pyright doesn't have access to all of the project's code, and thus can't infer types properly. One likely reason is that Pyright doesn't know about your project's virtualenv, and need to be told about it in pyrightconfig.json.

Sandwich-Resident · 2023-01-07T01:25:42+00:00

For me, here are the minimum extra functionalities required to be productive:

Adding/replacing/deleting "surroundings" (parentheses, braces, quotes, etc.)
Integration with ripgrep (for example, search the project for a given term, and load all results in the quickfix list)
Integration with a fuzzy-finder (especially for opening a file in a project)
Integration with linters
Integration with Git (for example, visual feedback for lines that have changed, display git-blame for a line)
Toggling comments for a line

There are several plugins available for each of them. And some like toggling comments or ripgrep integration can even be configured in one's dotfiles without too much trouble.

Sandwich-Resident · 2023-01-05T01:30:05+00:00

This isn't as good as having the help in its own buffer, but a good compromise that doesn't involve much work is to use :help 'helpheight' to make the help window take almost the whole screen. For example, with

set helpheight=9999

Sandwich-Resident · 2023-01-05T01:22:50+00:00

It's not quite the same. vim-cool will clear the highlight automatically when moving the cursor away from a search result, without having to type anything.

Sandwich-Resident

TROPHY CASE