doc: give neovim its own neovim.section.md #373090
Conversation
github-actions
bot
added
8.has: documentation
| ### Testing Neovim plugins {#testing-neovim-plugins} | ||
|
|
||
| #### neovimRequireCheck {#testing-neovim-plugins-neovim-require-check} | ||
| `neovimRequireCheck` is a simple test which checks if Neovim can requires lua modules without errors. This is often enough to catch missing dependencies. |
There was a problem hiding this comment.
| `neovimRequireCheck` is a simple test which checks if Neovim can requires lua modules without errors. This is often enough to catch missing dependencies. | |
| `neovimRequireCheck` is a simple test which checks if Neovim can load a plugin's lua modules without errors. This is often enough to catch missing dependencies. |
There was a problem hiding this comment.
I prefer the "require" mention that makes it clearer for the initiated (which this subsection is for).
| When `nvimRequireCheck` is not specified, we will search the plugin's directory for lua modules to attempt loading. This quick smoke test can catch obvious dependency errors that might be missed. | ||
| The check hook will fail the build if any failures are detected to encourage inspecting the logs to identify potential issues. | ||
|
|
||
| If you would like to only check a specific module, this can be manually added through plugin definition overrides in the [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). |
There was a problem hiding this comment.
| If you would like to only check a specific module, this can be manually added through plugin definition overrides in the [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). | |
| If you would like to only check a specific module, it can be added manually via the plugin definition overrides in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). |
There was a problem hiding this comment.
I'll rewrite it to the even shorter .., add it to the plugin definition in [overrides.nix]
| ``` | ||
|
|
||
| In rare cases, we might not want to actually test loading lua modules for a plugin. In those cases, we can disable `neovimRequireCheck` with `doCheck = false;`. | ||
|
|
There was a problem hiding this comment.
| Doing so will also prevent the plugin's test suite from running (if present). |
There was a problem hiding this comment.
@khaneliman is there any instance of us disabling doCheck just because of neovimRequireCheck ? If not let's delete this part.
There was a problem hiding this comment.
also there is a mix of neovimRequireCheck and nvimRequireCheck. Maybe you want to talk about neovimRequireCheckHook but it can be fixed in a separate PR.
There was a problem hiding this comment.
Most other language/framework sections contain some mention about the usage of doCheck = false; to skip the check phase. This is just an explanation of why you might want to use it. So I'd rather keep it but maybe update the example with some more accurate.
supermaven-nvim = super.supermaven-nvim.overrideAttrs {
# TODO: handle supermaven binary
doCheck = false;
};
I wanted to add instructions on how to configure neovim via the new wrapper but it was difficult mixing this with both the vim and old wrapper. Neovim differs enough from vim to warrant its own section IMO: 1. its wrapper is different (old wrapper close to vim's syntax, new one not so much) 2. treesitter is unique to neovim 3. the section about neovim plugins is unique to neovim as well. Not only that but it needs to expanded. At some point the doc unique to vim is going to exceed vim's. We can refer to vim's section to avoid duplication where it makes sense.
teto
force-pushed
the
teto/neovim-document-new-wrapper
branch
from
e9e1f74 to
ec51c28
Compare
nix-owners
bot
requested review from
hsjobeki,
GetPsyched and
fricklerhandwerk
| "index.html#vim-plugin-specificities" | ||
| "neovim-plugin-specificities": [ | ||
| "index.html#neovim-plugin-specificities", | ||
| "neovim-plugin-specificities#vim-plugin-specificities" |
There was a problem hiding this comment.
This should probably have been index.html#vim-plugin-specificities?
But great to see that @GetPsyched's work is useful to avoid documentation falling apart 😄
There was a problem hiding this comment.
maybe ? Because I had seen the PR about the redirection and all I had an idea of what was going on, otherwise I think the feedback would have surprised me more. I understand the idea behind the redirects but as a maintainer it's one additional hurdle to contribute to the doc and the UX frustrated me quite a bit. I spent more time trying to work out the redirections rather than the doc changes. Note that I contribute to the doc reluctantly as a last resort so I am already grumpy by then ^^'
First I think the errors should give a bit of context otherwise these errors popup without explanation.
I dont know how hard that is but if we could use redirects.jsonc instead of redirects.json, one could document the format a bit at the top of the file and document the redirects later (it might not matter much though).
the redirects executable differentiate between rename and moved content but it seemed articial. I believe this are no checks on the input arguments ? several times I ended up with wrong anchors or duplicates.
Is there any other possible value for path than "index.html" ? else we could default to that.
There was a problem hiding this comment.
Thanks for the feedback! And sorry that the experience was frustrating. Good point about input validation! The format is documented in the source code for the tool dealing with it, but it sounds reasonable to indeed document it in place. rename and move are different because the ultimate goal is to be able to change the page to where content is rendered, which is not implemented yet.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.