Largely, this is simply bumping versions and fixing a few configurations
that were changed in newer versions of the plugins.
I did however notice our package manager (packer.nvim) is orphaned now,
and I need to switch to a different one in the near future...
These gives us back the ability to use cspell, which was lost in the
transition from coc-nvim to our current lua based setup.
However, it requires the following to take effect:
1. Have nodejs installed (nvm is fine)
2. Run ':MasonInstall cspell'
3. Run ':PackerCompile'
4. Restart
All goes well, when you next open nvim, you should have cspell powered
spell checking and :LspInfo should show null-ls running.
Word substitutes triggered via:
@Buffer.Lsp.N.Leader.CodeAction
Next/Prev word (or other diagnostic) via:
@Global.N.DiagnosticNext
@Global.N.DiagnosticPrev
Where @ = nvim/lua/psoxizsh/key/bind.lua
neovim moved buf.formatting to buf.format, a while back, leaving this as
effectively setting `action = null`, which throws warnings on start; so
we fix that.
This commit enables nvim-cmp's cmdline completion support, overriding
the builtin neovim's.
We gain a nicer menu, more sources (paths, history), and a slightly more
intelligent listing with some support for file specific commands (e, r,
w).
We also switch out the 'path' completion source with 'async_path',
preventing delays / freezes when traversing slow or large fs trees
This is a plugin which overrides vim.prompt and vim.input handlers,
providing Telescope integration, and a much more pleasant experience
over the default menus provided by nvim.
The primary reason for this plugin is vim.lsp.buf.code_action/1, which
uses vim.input.
This allows callers of the struct to perform the more normal '='
assignment and have sane behavior.
Previously, this would not do what one expects when used with bind.Bind
or other bind.Group(s): it merely adds them to the Group object
directly, not adding it to the ._children table or downward propagating
the Group's settings.
This is fixed here, by adding a __newindex metamethod to the bind.Group
object, which checks to see if the addition is a known Bind or Group
type, and does the right if it is, falling back to the previous behavior
if it isn't
This commit unclobbers syntax and other errors that can occur when
loading a module.
Previously, we just pcall/2'd any inputs and silently assumed that any
error reported meant the module didn't exist. The changes within add a
third branch to the mix: EXISTS, NOT_FOUND, and LOAD_ERR.
We keep the previous behaviour of not throwing when an error is
detected, but we do print out a big, red, angry message now.
As a side note, this should also slightly improve performance, due to
less errors being thrown; on account of us manually detecting whether a
module exists or not.
plugin was renamed upstream, and now provides a hook for lspconfig,
making our override/1 work more in line with the standard 'override
the lspconfig.setup/1 param' that most of the other presets follow.
Silly mistakes:
1. Only running `vim.fn.expand/1` in the if check
2. Using `vim.fn.exists/1` for file checks (it doesn't do this)
Just rip the whole loop out, as probably a user isn't expecting
`[count]spell-action` to select different files depending on whether
they (and how many of them) exist.
Still leaves the problem of file creation, but ¯\_(ツ)_/¯
Due to the way we render `vim.diagnostic.open_float/1` on every `CursorHold`
event, this window will open over other floats that a user (may have)
opened, particularly `keys.Buffer.Lsp.N.ShowDocumentation`, which can be
frustrating.
This commit changes the behaviour to open the diagnostic float once per
cursor location, as this is probably what the user wants for the most
part. It is still possible for a user to run into the scenario where
they move to a diagnostic and open a float only for it to be replaced
on the `CursorHold`, but this should be much more infrequent.
Credit to github.com/wookayin for explaining how to do this.
See:
wookayin/dotfiles@ee687b036c
/nvim/lua/config/lsp.lua
#L249-L263
super keys are super powered binds accessible via <C-Arrow_Key>, for
example, <C-Left> opens the current file tree.
These binds are expected to be used often and provide 4 fundamental
features:
1. Terminal | <C-Up>
2. Fuzzy Search | <C-Right>
3. Workspace diagnostics | <C-Down>
4. File tree | <C-Left>
Each is powerful, but can be thought of as a different 'mode' that
should be intentionally invoked by the user.
Fuzzy search has perhaps the most potential of the supers, allowing for
everything from fuzzy file searches to direct integration with the
active LSP, allowing for fuzzy searching of actual symbols; functions,
classes, etc.
A builtin terminal is useful for running background jobs (compiles,
tests), and is generally useful for all the things a shell is when you
don't have a multiplexer of some kind (tmux, good terminal, etc)
A file tree is useful for IDE like movement between files and getting a
general view of the current workspace's git +-~ status. Not mention for
deletion and/or movement of files.
Last but not least, diagnostics are great for understanding the active
codebase's health, and for providing an aggregate overview of
outstanding issues in the code.
This plugin provides a concise listing of current diagnostic messages
across the workspace, grouped by file.
It replaces neomake / quickfix lists, and importantly is a lot less
buggy, faster and less intrusive than the previous solution.
You can toggle it via `<C-Down>`.
This commit removes (direct) FZF plugins in favor of telescope.nvim,
which provides a significantly nicer, native experience in doing fuzzy
searching.
The primary out of the box method for interacting with Telescope is
through the <C-Right> super key, which opens a 'meta-menu' of searchers
that you can choose from.
Some of the more interesting options are 'find_files', 'live_grep_search',
and 'lsp_symbols'. Note that you can use fuzzy searching for these. For
example, the chord <C-Right>ff<CR> brings up the 'find_files' menu.
Users are encouraged to create their own key maps for commonly used
searchers.
Also ignore Telescope windows in pear-tree as pear-tree's <CR> bind seems
to interact poorly with Telescope usage of <CR> (i.e it blocks it completely),
so we disable it
This commit adds integration for the builtin spell checker to our auto
completion engine.
Now, unfortunately, it is not nearly as intelligent as coc-spell-checker
is, and is missing _lots_ of common words that I/we use every day.
To alleviate this a bit, there are three spell files that can be used to
add/remove/override spell words:
1. <workspace>/.vim/words.utf-8.add
2. ~/.config/nvim/words.utf-8.add
3. $PSOXIZSH/nvim/spellfile/words.utf-8.add
You may also easily add / remove words from a given file via:
- [count]<Leader>ss: Whitelist word in `count` spell file, defaulting to
the lowest write-able file
- [count]<Leader>sw: Blacklist word in `count` spell file, defaulting to
the lowest write-able file
- [count]<Leader>sus: Undo whitelist word in `count` spell file
- [count]<Leader>suw: Undo blacklist word in `count` spell file
- ]s: Next bad word
- [s: Previous bad word
This commit adds (nvim-)cmp as our completion engine / framework.
We also add completion sources for (file)paths, buffer contents, LSP
actions and snippets -- courtesy of vsnip.
This provides similar functionality to coc's completion engine, but
with (much) better support for LSP actions, lua native key maps and
significantly more configuration options that can be easily overridden
but psoxizsh users.
We add similar default key maps as with what existed in coc, namely
that <CR> exits the autocompletion window, <C-Space> does the selected
LSP action, <Tab>/<S-Tab> cycles through options and <PageUp/Down>
scrolls documentation of the current item.
We also explicitly enable completion / snippet support in client capacities
sent to LSP servers, as many require this before offering completions
Adds support for treesitter syntax / grammars when editing files.
This is currently an experimental neovim feature but is (very) likely to
be merged into the upstream in one of the next releases.
This is a plugin for reporting '$/progress' status messages from neovim.
Realistically, only (some) LSP servers actually use this, but it
provides a clean, minimal method for understanding what an LSP is
working on at the minute.
`Server.Rust`, `Server.Lua` and `Server.Json` support it at a minimum,
from my personal testing
This plugin provides project (and user) local configuration files for
LSP settings, similiar to coc-settings files.
By default, it will search
- $HOME/.config/nlsp-settings/<language-server>.json
- <project-root>/.nlsp-settings/<language-server>.json
for configuration, automatically updating the language server with the
settings found within. These override any settings set within lua...
bare this in mind.
You may access the associated files via:
:LspSettings [local] <language>|buffer
This plugin provides the tools for initializing language servers, using
the builtin neovim LSP client. It provides the major low level glue for
actually starting and configuring a given language server; however it
**does not** ensure that the actual language server is present on the
system / in PATH.
That function is handled by mason / mason-lspconfig, which will prompt
the user to install the necessary server(s) upon calling
`lspconfig[$server].setup { ... }`.
We provide a default on_attach function the sets up some default key
maps for LSP related functionality, loading a user overridable map of
language servers and their associated setup objects or functions.
Note that "setting up" a language server is not the same as loading it,
which is a considerably more expensive operation. Hence, we make no
effort to lazily setup language servers.
These were selected as they seem generally useful in everyday usage of
neovim. Vim/Lua is obvious, Json and Yaml is generally useful for
config editing.
These objects provide a nice abstraction over the underlying
complexities of configuring language servers in native Neovim.
The idea is to allow users of the module to define Server/s that can
just be included somewhere and have them activate with fuss.
That said, we *do* want ways of configuring the underlying systems, and
this module provides two, one for direct consumers of this module
(Spec.setup), and one for users *of predefined Servers*, in the form of
Server.with/1.
This commit removes all vimpeccable (vimp) usage from the code base, as
it has been superseded by 'psoxizsh.key'.
In addition to simplifying the code, this also removes the annoying
spurious errors that would be generated when reloading configuration.
One thing to note: this commit also remove most of the LSP config we
have for coc.nvim. This is intentional, and will be corrected via a
future patchset utilizing the native neovim LSP client, as coc has
become annoying to maintain.
This commit adds a file that users can use to lookup available key binds
that are set.
The big benefit here is largely discoverability, as psoxizsh users no
longer are required to search thorough the entire code base looking for
binds.
That said, we *only* cover those explicitly set by psoxizsh, but
covering any created by plugins that may be used.
Still, this is a significant improvement compared to the previous
situation, and more importantly; prevents the situation from getting
worse as we add more plugins.
NOTE: Must go through prior work (util/keymap, vimp) and codebase, to properly
search and replace all instances of key binding
This commit adds wrapper objects around vim.keymap functionality.
Bind represents a single key bind, which can be register/2'ed with
Neovim. By default, Bind enables noremap and silent (:h map-arguments)
by default, as this is almost always what a user wants.
BindGroup(s) are DAG collections of child BindGroup(s) inner nodes
and Bind leaf nodes. Options are passed down the tree, though they
may be overridden by child objects.
Together they allow callers to create composable, lazy key bind
groupings, that can be instantiated together, while deferring the
implementation and activation of such groups.
Generally speaking, the big idea is to provide several well known
group 'aliases', for example, bind.Global, bind.User or bind.Lsp,
and let users override key binds in these groups, while the actual
functionality is provider (Bind.action) is opaque to them.
This is a much prettier frontend for the vim.notify API, which is used
by a lot of plugins to communicate information and/or errors.
Try it out yourself:
:lua vim.notify('Hello, world!', 'info', { title = 'Testing Notify'})
- Enable toggleterm support (it now recognizes TT windows)
- Use gitsigns for branch detection (faster than running external
git commands)
- Remove 'italic' from branch section highlights
Paul Stemmet