See the below issue
https://github.com/jose-elias-alvarez/nvim-lsp-ts-utils/issues/87
We went with null-ls because we wanted formatting with prettier. Also
null-ls was recommended by nvim-lsp-ts-utils.
The advantage of null-ls is it provides formatting and diagnostics
together in one package.
However, we will get prettier by another means and for linting switch to
nvim-lint.
It has a few more things than asyncdo and automatically handles makeprg
not that setting a custom command to handle makeprg with asyncdo was
a problem but still. Should also be useful for fugitive git push,
believe it will use dispatch when available.
See the actual fix upstream
32ddc125ec
This could be probably unrelated and just was fixed in neovim core
perhaps. Either ways we do not need to do this anymore.
The signature help sometimes stays open even after moving away from
the function. Sometimes it conflicts with the auto completion pop-up
making it difficult to see one of the two windows.
termdebug seems good enough so just drop this. Or we will use nvim-dap
if needed. However, termdebug should be enough really. We also just
found gdb-dashboard which seems great adding just the necessary UI bits.
With LSP providing formatting have not used this in more than a year.
Just drop it. Also it is pretty stupid to look for everything global &
not use language build tool to pick the correct formatter and its
configuration.
Now that we have migrated to clang LSP for C, the only reason for
keeping it around was using it to find files in gst-build repository
which was structured in such a way that fzf and rg could not be used.
Now that GStreamer has moved to monorepo setup, we can use fzf and
rg just like in any project. No need for cscope anymore.
For some reason without adding the snippets to the runtime path,
snippets do now show up in completion.
Found the solution here though the issue is on Ultisnips
https://github.com/hrsh7th/nvim-cmp/issues/241
nvim-compe has been deprecated. While we tried to make it a few days
without any completion support, in javascript/typescript could not get
the default omnicompletion to work at all. It is possible that this
could be due to nvim-lsp-ts-utils/null-ls but who is gonna debug.
Also tried MUcomplete but it just would not work. There are open issues
on this. See https://github.com/neovim/neovim/issues/12390 and also
https://github.com/lifepillar/vim-mucomplete/issues/179.
So here we are with nvim-cmp. Some observations in comparison to compe
before. Using buffer completion seems not possible as most of the times
LSP completion items then do not turn up. Do not know if this is server
specific but at least it is the case with Rust. compe seemed better
performance wise especially in tsserver and considering the buffer
problem mentioned above. Also, even with vsnip added as the completion
source can't seem to get any snippet specific completions working.
Could have ditched all completion support if I did not have to use
tsserver but need it for work currently. So we will stick to enabling
this and hopefully it improves in future.
Fuck nodejs, javascript and typescript.
For references see,
https://github.com/kristijanhusak/neovim-confighttps://github.com/sQVe/dotfiles/tree/master/config/nvim
Now that neovim runtime can also source lua files from traditional vim
runtime directories like after/plugin/ftplugin etc, move all plugin
configuration files to after/plugin.
The plugin is a pretty small ftplugin. Just add it to our ftplugin.
This also fixes the issue where this plugin did not take affect
when using interactive rebase from within fugitive.
Drop the syntax highlighting plugins for fish and nix and switch to
treesitter. The ftdetect is taken from the respective plugins.
We might need to add the indent specific scripts for fish and nix
later since we are not enabling indent with treesitter.
We have been mostly relying on diffconflicts plugin to resolve merge
conflicts. For complex merge conflicts, it becomes difficult to
understand which conflict hunk to pick. The syntax highlighting also
stopped taking effect due to treesitter probably. So just drop this.
Introducing a mapping to jump among conflicts would be helpful.
We let the syntax highlighting entries in our color scheme be, just
in case we decide to revisit this.
We drop vim-system-copy and will explicitly use registers when required.
Add nvim-peekup to help with registers and vim-signature for marks. Some
additional helper bindings for working with marks are added as well.
This reverts commit 86de71d5da.
This plugin seems to create problems for things that should work. For
example, trying to paste with 'p' triggers which-key when it should not.
Disabling everything in setup except for Leader prefixed keys does not
work either.
With nvim-bqf when opening the quickfix list, it jumps around the opened
buffers. For example, when calling LSP reference on a variable in buffer
one, it jumps to buffer three after the quickfix list opens. This is
annoying, so dump it. The preview feature has not been that helpful
anyways.
We use galaxyline for the status line and it already provides
LSP diagnostics info. So drop lsp-status. While the progress
message during the loading in status line is nice, may be will
incorporate it later by picking only the required pieces.
While at it, expose all diagnostics via statusline using galaxyline
components.
With most of our operations now being done through fzf + git command
line or lazygit, we primarily only require the log & blame facilities.
The blame interface in Gina is confusing.
This time however, we include some nice helper functions of our own.
vim-signify recently fixed the below issue which was a problem earlier.
https://github.com/mhinz/vim-signify/issues/345
Considering that gitsigns exhibits a problem where the complete sign
column is marked while in the middle of a rebase, switch back to using
signify.
Not sure what changed in recent releases for either nvim, packer or
lspconfig plugins, but, our custom LSP configuration file seems to
not be loaded or have any effect when specified via packer's config
directive. So load it manually in init.
While we dropped diffconflicts earlier and switch to vanilla vimdiff,
two way merges are definitely better than three way merges. 3 way merge
as in gina or vimdiff is extremely confusing except for may be the
simplest of merge conflicts.
conflict-marker and diffconflicts should let us handle all cases.
We added edita to be able to do interactive rebase inside neovim
terminal which Gina does not support by default.
See issue
https://github.com/lambdalisue/gina.vim/issues/276
Mostly haven't been using this, just relying on spawning a separate pane
in tmux or kitty window to do the rebase. So drop this.
Sanchayan Maity