Using lazy-events.nvim we can create custom events (such as the LazyVim
equivalent LazyFile event) based on other events (i.e. a grouping), on
globbing files in the current dir, or on arbitrary custom logic.
For now, any plugins which require files to be present to work are
loaded with the 'LazyFile' event.
Any plugins which need to be loaded when opening a directory with vim
are loaded with the 'StartWithDir' event (essentially only neo-tree for
now). Similarly mini.starter is loaded on the `StartScreen` event.
Any plugin which only makes sense to run in a `.git` dir (gitsigns etc)
will only run on the `LazyProject:git` event.
Automatically opens dap-view when in debugging session (and closes when
done), sets some breakpoint jump logic and makes the gutter symbols
nicer.
Adds keybinds for most of the dap operations with
`<localleader>d<something>` where something is the operation (i.e. `c`
for continue, `b` for breakpoint and so on).
For now there is no strict reason to have it disabled, even if I don't
use it much. At the same time I can always re-disable it if I need the
bracketed movement for something more important later down the line.
In preparation for adding debugging we change the bracket movement
between diagnostics from `[d`/`]d` to `[e`/`]e` instead.
This will be a big switch in muscle memory for me and I hope I can adapt
to it pretty quickly, but at least mnemonically it still makes sense
since we jump between [E]rrors (or warnings but good enough).
mini.bracketed never received its configuration which is the reason I
had some issues in the past. It was simply wrapped in one too many
layers of tables. Now works as intended.
Treesitter had to run as a non-versioned (trunk-tracking) plugin for a
while since there was no updated version released.
Now that it is we can return to a nicely versioned tag.
Sad but I'll have to face it - I've never successfully used
criticmarkup in, by now, 6 years of professional academic writing.
The plugin also does not work as well as it should (anymore?) with my
current neovim setup. The `:Critic` command works neither with accept
nor reject and the different highlights are presumably overwritten by
treesitter queries.
Now, all of those _could_ be fixed but as I say above, I have never
successfully used the markup. Perhaps one day it could be implemented in
a slick nvim lua plugin with hiding and extmarks which mimicks a truly
nice review editing experience. But not today.
Old versions of render-markdown.nvim suggested renaming it to another
plugin name, but this seems to not be the case anymore. I removed both
for the time being and it fixed a long-standing issue I had with the
plugin.
Whenever there is a left-over quote (') or double quote ("), if we want
to 'close' it, mini.pairs will by default add a new pair (e.g. """)
instead. This simply changes it to close the pair. Makes some
'double-quote' pairings harder (e.g. we have a python dict: {"name"})
and want to add another {"name""value"} into it, but this happens
relatively rarely in my use cases. The first on the other hand happens
frequently enough to be an annoyance.
Additionally, did the same for back-ticks so we can more easily create
triple backticks ``` which are essential in many literate programming
markup languages (markdown, quarto, rmd and so on).
Makes it easier to read lists, and also easier to work with
markdownlint even if it has not been configured for a given repository
(since its list indentations default to 2 spaces).
For some versions apparently markdown preview could not be built anymore
with the suggested installation in the readme. Instead it requires the
build function to be called through a string from lazy.
See:
https://github.com/iamcco/markdown-preview.nvim/issues/690
When in a ZK dir I do not want any marksman diagnostics polluting my
interface since the linking in (my) ZK is based on anchor IDs and not
full filenames/titles. Thus, every single link will be detected as
non-existent by marksman.
This commit ensures that when in a zk-enabled directory, each
non-existent link diagnostic will be filtered before presenting
diagnostics.
Nushell lsp is now integrated directly into the 'nu' command. This
update stops mason from trying to install a 'nushell' LSP and simply
activates the nu-internal LSP if it finds the correct executable
instead.
Fixes #1ef7570.
We implement our own autostart-aware lsp register function. Any lsp
which has the option {autostart=false} set at their config root will be
not automatically enabled and can instead be enabled on demand.
We now have the usual 'undone' ([ ]) and 'done' ([x]) states, but
express 3 further ones that are _somewhat_ standardized:
- [o] this one is 'doing', in-progress
- [-] this one is 'indeterminate', we're not sure
- [~] this one is 'deleted', never to be done
Makes the plugin less intrusive (will now only autocomplete on <M-p> or
<leader>ap). Can select suggestion with <M-]> or <M-[>, and accept with
<M-p> in-text or <CR> in-panel.
Still automatically started when invoking CodeCompanion chat.
Should return the mason environment for lsp servers to be able to set it
in the 'core/languages.lua' list.
However, currently it is initialized too early (I think), before
mason.nvim, and thus never gets the initialized env var.
So far if LSP declarations in 'core/languages.lua' were duplicated (e.g.
the 'astro' filetype and the 'vue' filetype both declare the
'typescript' lsp), one would simply overwrite the other. That is fine as
long as there is no custom setup, but if there is one of them is lost.
This commit changes it so that the different configurations extend each
other. The 'latter' one still overwrites the former but this is just
what must happen if there should be conflicting setups.
May increase loading time slightly.
Since it is technically vim-internal (and relatively rarely used unless
to debug things), I have moved the shortcut for this function from
`<leader>sh` (show-history) to `<leader>vp` (vim-print-messages).
The 'p'-suffix is a little unfortunate but currently h/H/m are all taken
in this vim-internal submenu.
The reasoning behind this is that the 'show' menu is intended primarily
for user-facing, middle-of-work tasks and windows that help me
accomplish goals when actually working and getting things done.
Showing the fidget history does not do that, but allows
introspection into the vim editor history. So, it should accordingly
live under the 'vim' menu. Additionally, it frees space in the
'show' menu and lets me/the user forget about the functionality
until it is needed.
Allows quickly listing and working with taskwarrior tasks from within
neovim. Show a floating `:NeoWarriorOpen` window with `<leader>sw` or a
vertical neowarrior buffer with `<leader>sW`.
