Update and fix small breaking change in new conform by specifically
setting lsp formatting as fallback. Move to explicit ruff format import
organizing and remove tailwind css lsp for the time being.
When a `.zk` directory is found in the current root directory of the
marksman project, the lsp is disabled.
This is because zk delivers its own lsp server with correct following of
note ids instead of full file names which marksman expects and fails to
find.
Since ltex-lsp eats quite a lot of resources and takes a while to start
up we don't always want it enabled for every prose file. This commit
ensures that it only starts up when spellchecking is enabled for a
buffer (through the custom user command `SpellToggle`).
Switch out mason-tool-installer for mason-conform.nvim and
mason-nvim-lint as respective wrappers for automatically installing
formatters and linters.
Follows the same principle as mason-lspconfig.nvim (in fact, the repos
are mostly based on the same code) and apply the concept to the other
tools: Whatever is enabled in the respective plugins (lspconfig,
nvim-lint and conform.nvim) will automatically be installed by mason.
This is really neat and basically takes care of me ever having to
interact much with Mason itself or manually set up the tools to be
installed. All I have to make sure is that they're updated once in a
while.
As a first step to disentangle the ide.lua module into completion,
formatting, lsp (and maybe lint?), this separates the completion module
into its own file.
Now we can either fetch the python venv basefolder
(`require('core.util').get_python_venv_basefolder()`) or specifically
the python binary contained within (`.get_python_bin()`).
Additionally, the venv result should be cached for the duration of using
nvim so that we only have to fetch it once, regardless of how many
modules require it.
Switched pyright to basedpyright as it adds a couple noteworthy
rules and some functions that are otherwise exlusive to pylance.
Especially useful for me are semantic highlighting as well as
inlay hints (now that nvim supports it from 0.10 onwards).
LSP attachment would complain if it did not find an existing dict to
access in the `settings.python` section of the python lsp dictionaries.
This fixes that by creating an empty dict if nothing exists yet,
essentially functioning as null-check.
Add 'glances.nvim' plugin which shows the LSP references, definitions and
implementations in a very nice floating preview window. (Previously we
used Telescope which is still called if the glances plugin does not
exist.)
Can preview, scroll in the floating window, go to the destination, open
the destination in vert/horiz splits.
Using mason-tool-installer we ensure everything is installed correctly.
Need to improve the collection of things to install. Currently we just
do everything in lsp configuration file, even the non-lsp things
(formatters/linters) which should be sourced where they belong not
in that file.
Moved the mapping to show lsp info window from `<localleader>li` to
`<leader>vs`.
Local leader +l mappings should be reserved for lsp functionality,
while we have a whole +v layer to grab (meta) information about our
vim installation. It fits in there much better.
In the process of moving away from null-ls, added formatting with the help
of conform.nvim. Brings one new command, :ConformInfo which can also be
reached via `<leader>vc`.
AutoFormat on saving remains disabled by default but can be enabled with
:FormatEnable (and disabled again with :FormatDisable) or quickly through
`<localleader>lL`.
Manual formatting works like before with `<localleader>ll`. Uses the
formatters set in the plugin (similar setup to null-ls before) but
automatically falls back to lsp formatters if it does not have its own
and lsp has one enabled.
HACK
Added support for nushell lsp (not yet available to automatically install
through mason integration) and for nushell treesitter (VERY manual
installation as of right now).
Will work for testing out the shell and its nvim integration but
definitely has to be integrated better in the future.
When writing something we often want to ideally hide the long comments
added to the end of any line in-progress as virtual text currently.
This simply adds an auto-command to hide when entering and show again
when exiting insert mode, simple but hopefully useful.
If you want to hide buffer diagnostics for any reason, there is now a
quick mapping reachable through the usual lsp submenu: `<localleader>lo`
(I suppose the mnemonic would be 'lsp off').
It toggles them enabled and disabled and only affects the current
buffer.
Removed notification on activating a python venv.
It should just work, transparent to the user and we do
not need a big ol' notification each time we enter
a file.
Mapped to `[D` / `]D`, reflecting the capitalization of going to the
next general diagnostic (`[d`/`]d`).
Now it is similar to spelling mistakes and spelling errors
(`]s[s`/`]S[S` respectively).
When writing a markdown or similar document, vale will automatically
be enabled if there is a '.vale.ini' or '_vale.ini' file (and a
corresponding styles folder) in the project root directory.
Otherwise, vale stays disabled.
The plugin was not loading since lazyloading was not given an event
to start it with. Now, anytime any zk command is given, or we enter
a prose-like filetype the plugin is sourced.
The zk lsp on the other hand was started twice whenever the plugin
was loaded, since we also loaded it through the lspconfig manually.
This commit fixes both issues by sourcing and plugin and letting the
plugin load the lsp as well.
Moved plugins into individual component module files which are
automatically required by lazy.nvim. Should make everything a tiny bit
more modular, or at least prepare the way for true modularity if I ever
have the time on my hands to ensure everything works with missing
modules.
Moved core settings into their own directory (`core`), and created a
`personal` folder which contains functions/plugins I wrote that do not
necessarily have to be their own imported plugin yet.
Finally, extended the utility functions a little, so we can detect if a
plugin exists and change e.g. key maps based on that (once again,
extending modularity a little more). Some simple attempts have been made
at that in the `mappings.lua` file, though it is nowhere near extensive
yet - most keymaps are still set regardless of plugin availability.
However, with this slimmer base to work off of, I feel more confident in
changing future things about this setup a little more ad-hoc without
having as many ripple repercussions as before.
