Not sure if we ever really needed this considering that we work on open
source projects, where we need only push the branch from which we raise
the MR. Pretty much the same for current client work as well. Are tags
ever required for such scenario?.
This allows us to generate a breakpoint location we can use in the gdb
command file or on command line and also copies it to the clipboard thus
allowing us to easily paste it.
Support for use of floating windows for completion menus landed
upstream. It introduced a new feature but also broke things. Having
native_menu set completely breaks auto completion.
While at it, add mapping for scrolling docs. Also add support for it
in color scheme.
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.
nvr seems to allow opening a file at specified line just like with
regular nvim which seems to not work for floaterm. So when in neovim
terminal vgrep -s opens the file at correct line while in floaterm it
just opens the file and puts us at the first line. Basically something
like nvim +99 file.c does not work for floaterm.
For the most part adapted from
https://gavinhoward.com/2020/12/my-development-environment-and-how-i-got-there/
Also contains support for opening current line in neovim.
This assumes we are running inside neovim terminal and hence the use of
nvr viz. neovim-remote. We will try adding support for kitty window and
single instances later if possible.
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.
The required capabilities to be set are already correctly set by
nvim-cmp, no need to set them again. We had added that to enable rust
snippet expansion earlier.
Also see older revisions of this document.
https://github.com/neovim/nvim-lspconfig/wiki/Snippets
vim.diagnostic framework is now available and can be used outside of
LSP. This means the same functions can now work for plugins providing
diagnostics via this framework like nvim-lint and null-ls.
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.
