Closed cristobalgvera closed 3 weeks ago
Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:
Proper conventional commit scoping:
If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin
If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error
[x] Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above
[x] README
is properly formatted and uses fenced in links with <url>
unless they are inside a [title](url)
[x] Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).
[x] Proper usage of opts
table rather than setting things up with the config
function.
[x] Proper usage of specs
table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).
I'm thinking to refactor this after the PR approval, in order to follow the standard process to map keybingings used in here
📑 Description
Add mappings to simplify the usage of watch-related commands when using
neotest
.It also refactor the keybindings to follow current standards using an
opts
function instead of a table.ℹ Additional Information
The API for the usage of
neotest.watch.stop()
is not well defined in terms of the type information for the usage.This creates the necessity to use
@diagnostic disable-next-line: missing-parameter
.For a closer look, see https://github.com/nvim-neotest/neotest/blob/master/doc/neotest.txt#L626