This doesn't handle looking for workspace level files, but will stop
the "Add word to dictionary" code action from creating random
cspell.json files in whatever vim considers to be the current working
directory.
Eventually, I'd like to move this all into neoconf.json, but this is
better than the current, non functional state
these are a collection of functions that we have built in house, those
their insides replaced to work better with the new plugin manager
namely
- Format
- OpenConfig
- ToggleGutter
We remove the old bind.lua functionality for creating recursive auto
initialized groups of bindings, replacing it with a simpler data
structure that only provides a common, simple mechanism for storing all
the information needed to make a new key bind in the future.
This change is good for two reasons:
1. the luals LSP can now provide autocompletion for keybinds
2. the module is much simpler, and can be extended easily to map the
existing data structure into other formats, like the one used by
lazy.nvim's keys map, or Neovim's own vim.keymap.set
We also update, refactor and rename the old map.lua file to binds.lua,
so that we remain consistent in our terminology with Neovim itself
Lastly, we touch up key/init.lua to handle these changes, and make it
easier for others to potentially create their own keybinds
These are simple "prebaked" functions that can modify the PsoxizshConfig
object before it is utilized further.
It allows the primary users of this repo to have seperate "profiles"
that they can maintain in the main code base, while also allowing others
to just pass a similiar function to PsoxizshConfig.profile.
This commit rewrites the psoxizsh init to conform to lazy.nvim plugin
schema.
This is a port of the old early/pre/post/late stages we used to use to
functions we can call during our toplevel module's eventual setup()
call.
We should probably add optional callbacks to each so that users can
retain the older method of initialization...
This is our inhouse overrides over LazyVim's key maps for the LSP on_attach
function.
Unfortunately there's no good way to do this, other than directly
mutating the key binds LazyVim creates
Adds back some of the functionality of the late lsp.server, such that we
can paper over the exact implementation details of _how_ we're enabling
the language server.
In practice, this will allow us to create a bunch of preset
PsoxizshLspServer types, which users can then opt into enabling in their
plugin/* configs
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.
Paul Stemmet