diff3 as conflict style was required by vim-mergetool. It is not
required by the current plugins we are using.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Also add the conflict-marker plugin. This should also be useful
for doing rebases and resolving conflicts. Might drop one later
if one of them serves all the purposes in all cases.
While at it, add unimpaired style bindings for moving between
tabs. This is required since :DiffConflictsShowHistory opens
a new tab and default tab navigation bindings gt/gT at least
are binded to something else in python.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
We do not want project specific or project local information to be
available among various neovim instances. It should either be managed
by sessions or should not be stored on neovim exit.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
vim-fugitive from Tpope is synchronous on neovim. It is
asynchronous on vim when vim-dispatch is available but for
neovim it will always be synchronous. Gina is asynchronous
by default and does not freeze on large repos like fugitive
does. So drop fugitive, other plugins and settings dependent
on it.
While at it, also add some more good things from git gutter
and some shortcuts.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
We switched away from Sonokai due to high load times in 20ms or more but
there isn't a monokai variant which is better than this. Gruvbox got
annoying after a while. A darker contrast would have been preferred but
no other fits the bill.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
It seems since we are using hard coded colors, so we do not need the
auto command at all. Getting rid of it gives the right results.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
This theme is quite fast to load though slightly less nicer than
sonokai, the sonokai theme can take 20-30ms during load. Load times for
gruvbox8 seem to be around 2-2.5ms.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
LSP does not work all the time. Either client breaks, server breaks or
it does not work because of the project structure. Removing LSP for the
umpteenth time.
asyncomplete does not seem to work at all for tags. For example, in the
gst-build directory the generated tags file can be 200MB+ in size. Even
with the file size limit set to unlimited it does not seem to give any
tag suggestions at all. Same is the case for Haskell.
Mucomplete can be slow in such cases where tag file is very large or
search space is extensively large and being synchronous this is to be
expected. To alleviate this, it is necessary to have a minimum prefix
length of 2 and perhaps trigger completion only when required. However,
this was still not good enough.
We are back to deoplete with custom source configuration. It is pretty
clear vimscript solutions are not up to the mark. Enable python provider
and also reintroduce language specific solutions like racer and jedi.
Refactor out language/file type specific settings. init.vim should only
have global keybindings, plugins and plugin settings. Also some other
minor cleanups, additions and rearrangements.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Enable to process line and column jump specifications in file paths as found
in stack traces and similar output
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
This setting results in the quickfix list having the same result
multiple times if by mistake we run the same search again.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
While we have fzf, for situations where we want to search and load
results in quickfix or location list vim-grepper should come in handy.
vim-qlist enchances ]i/I related bindings for search to load then in
quickfix list.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
