mirror of
https://github.com/NotAShelf/nvf.git
synced 2025-09-06 10:21:31 +00:00
docs: format via deno fmt
This should be a pre-commit hook in the future.
This commit is contained in:
parent
e43a067cae
commit
a196e9610f
11 changed files with 114 additions and 117 deletions
|
@ -1,8 +1,8 @@
|
|||
# Custom Plugins {#ch-custom-plugins}
|
||||
|
||||
**nvf**, by default, exposes a wide variety of plugins as module options
|
||||
for your convenience and bundles necessary dependencies into **nvf**'s runtime.
|
||||
In case a plugin is not available in **nvf**, you may consider making a pull
|
||||
**nvf**, by default, exposes a wide variety of plugins as module options for
|
||||
your convenience and bundles necessary dependencies into **nvf**'s runtime. In
|
||||
case a plugin is not available in **nvf**, you may consider making a pull
|
||||
request to **nvf** to include it as a module or you may add it to your
|
||||
configuration locally.
|
||||
|
||||
|
@ -11,12 +11,12 @@ configuration locally.
|
|||
There are multiple ways of adding custom plugins to your **nvf** configuration.
|
||||
|
||||
You can use custom plugins, before they are implemented in the flake. To add a
|
||||
plugin to the runtime, you need to add it to the `vim.startPlugins` list in
|
||||
your configuration.
|
||||
plugin to the runtime, you need to add it to the `vim.startPlugins` list in your
|
||||
configuration.
|
||||
|
||||
Adding a plugin to `startPlugins` will not allow you to configure the plugin
|
||||
that you have adeed, but **nvf** provides multiple way of configuring any
|
||||
custom plugins that you might have added to your configuration.
|
||||
that you have adeed, but **nvf** provides multiple way of configuring any custom
|
||||
plugins that you might have added to your configuration.
|
||||
|
||||
```{=include=} sections
|
||||
custom-plugins/configuring.md
|
||||
|
|
|
@ -12,9 +12,9 @@ entries in nvf:
|
|||
2. `globalsScript` - used to set globals defined in `vim.globals`
|
||||
3. `basic` - used to set basic configuration options
|
||||
4. `optionsScript` - used to set options defined in `vim.o`
|
||||
5. `theme` (this is simply placed before `pluginConfigs` and `lazyConfigs`, meaning that
|
||||
surrounding entries don't depend on it) - used to set up the theme, which has to be done before
|
||||
other plugins
|
||||
5. `theme` (this is simply placed before `pluginConfigs` and `lazyConfigs`,
|
||||
meaning that surrounding entries don't depend on it) - used to set up the
|
||||
theme, which has to be done before other plugins
|
||||
6. `lazyConfigs` - `lz.n` and `lzn-auto-require` configs. If `vim.lazy.enable`
|
||||
is false, this will contain each plugin's config instead.
|
||||
7. `pluginConfigs` - the result of the nested `vim.pluginRC` (internal option,
|
||||
|
|
|
@ -1,25 +1,23 @@
|
|||
# Using DAGs {#ch-using-dags}
|
||||
|
||||
We conform to the NixOS options types for the most part, however, a noteworthy
|
||||
addition for certain options is the [**DAG
|
||||
(Directed acyclic graph)**](https://en.wikipedia.org/wiki/Directed_acyclic_graph)
|
||||
addition for certain options is the
|
||||
[**DAG (Directed acyclic graph)**](https://en.wikipedia.org/wiki/Directed_acyclic_graph)
|
||||
type which is borrowed from home-manager's extended library. This type is most
|
||||
used for topologically sorting strings. The DAG type allows the attribute set
|
||||
entries to express dependency relations among themselves. This can, for
|
||||
example, be used to control the order of configuration sections in your
|
||||
`luaConfigRC`.
|
||||
entries to express dependency relations among themselves. This can, for example,
|
||||
be used to control the order of configuration sections in your `luaConfigRC`.
|
||||
|
||||
The below section, mostly taken from the [home-manager
|
||||
manual](https://raw.githubusercontent.com/nix-community/home-manager/master/docs/manual/writing-modules/types.md)
|
||||
The below section, mostly taken from the
|
||||
[home-manager manual](https://raw.githubusercontent.com/nix-community/home-manager/master/docs/manual/writing-modules/types.md)
|
||||
explains in more detail the overall usage logic of the DAG type.
|
||||
|
||||
## entryAnywhere {#sec-types-dag-entryAnywhere}
|
||||
|
||||
> `lib.dag.entryAnywhere (value: T) : DagEntry<T>`
|
||||
|
||||
Indicates that `value` can be placed anywhere within the DAG.
|
||||
This is also the default for plain attribute set entries, that
|
||||
is
|
||||
Indicates that `value` can be placed anywhere within the DAG. This is also the
|
||||
default for plain attribute set entries, that is
|
||||
|
||||
```nix
|
||||
foo.bar = {
|
||||
|
@ -41,8 +39,8 @@ are equivalent.
|
|||
|
||||
> `lib.dag.entryAfter (afters: list string) (value: T) : DagEntry<T>`
|
||||
|
||||
Indicates that `value` must be placed _after_ each of the
|
||||
attribute names in the given list. For example
|
||||
Indicates that `value` must be placed _after_ each of the attribute names in the
|
||||
given list. For example
|
||||
|
||||
```nix
|
||||
foo.bar = {
|
||||
|
@ -57,8 +55,8 @@ would place `b` after `a` in the graph.
|
|||
|
||||
> `lib.dag.entryBefore (befores: list string) (value: T) : DagEntry<T>`
|
||||
|
||||
Indicates that `value` must be placed _before_ each of the
|
||||
attribute names in the given list. For example
|
||||
Indicates that `value` must be placed _before_ each of the attribute names in
|
||||
the given list. For example
|
||||
|
||||
```nix
|
||||
foo.bar = {
|
||||
|
@ -73,9 +71,8 @@ would place `b` before `a` in the graph.
|
|||
|
||||
> `lib.dag.entryBetween (befores: list string) (afters: list string) (value: T) : DagEntry<T>`
|
||||
|
||||
Indicates that `value` must be placed _before_ the attribute
|
||||
names in the first list and _after_ the attribute names in the
|
||||
second list. For example
|
||||
Indicates that `value` must be placed _before_ the attribute names in the first
|
||||
list and _after_ the attribute names in the second list. For example
|
||||
|
||||
```nix
|
||||
foo.bar = {
|
||||
|
@ -87,18 +84,18 @@ foo.bar = {
|
|||
|
||||
would place `c` before `b` and after `a` in the graph.
|
||||
|
||||
There are also a set of functions that generate a DAG from a list.
|
||||
These are convenient when you just want to have a linear list of DAG
|
||||
entries, without having to manually enter the relationship between
|
||||
each entry. Each of these functions take a `tag` as argument and the
|
||||
DAG entries will be named `${tag}-${index}`.
|
||||
There are also a set of functions that generate a DAG from a list. These are
|
||||
convenient when you just want to have a linear list of DAG entries, without
|
||||
having to manually enter the relationship between each entry. Each of these
|
||||
functions take a `tag` as argument and the DAG entries will be named
|
||||
`${tag}-${index}`.
|
||||
|
||||
## entriesAnywhere {#sec-types-dag-entriesAnywhere}
|
||||
|
||||
> `lib.dag.entriesAnywhere (tag: string) (values: [T]) : Dag<T>`
|
||||
|
||||
Creates a DAG with the given values with each entry labeled
|
||||
using the given tag. For example
|
||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
||||
For example
|
||||
|
||||
```nix
|
||||
foo.bar = lib.dag.entriesAnywhere "a" [ 0 1 ];
|
||||
|
@ -117,9 +114,9 @@ foo.bar = {
|
|||
|
||||
> `lib.dag.entriesAfter (tag: string) (afters: list string) (values: [T]) : Dag<T>`
|
||||
|
||||
Creates a DAG with the given values with each entry labeled
|
||||
using the given tag. The list of values are placed are placed
|
||||
_after_ each of the attribute names in `afters`. For example
|
||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
||||
The list of values are placed are placed _after_ each of the attribute names in
|
||||
`afters`. For example
|
||||
|
||||
```nix
|
||||
foo.bar =
|
||||
|
@ -140,13 +137,13 @@ foo.bar = {
|
|||
|
||||
> `lib.dag.entriesBefore (tag: string) (befores: list string) (values: [T]) : Dag<T>`
|
||||
|
||||
Creates a DAG with the given values with each entry labeled
|
||||
using the given tag. The list of values are placed _before_ each
|
||||
of the attribute names in `befores`. For example
|
||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
||||
The list of values are placed _before_ each of the attribute names in `befores`.
|
||||
For example
|
||||
|
||||
```nix
|
||||
foo.bar =
|
||||
{ b = 0; } // lib.dag.entriesBefore "a" [ "b" ] [ 1 2 ];
|
||||
foo.bar =
|
||||
{ b = 0; } // lib.dag.entriesBefore "a" [ "b" ] [ 1 2 ];
|
||||
```
|
||||
|
||||
is equivalent to
|
||||
|
@ -163,10 +160,9 @@ foo.bar = {
|
|||
|
||||
> `lib.dag.entriesBetween (tag: string) (befores: list string) (afters: list string) (values: [T]) : Dag<T>`
|
||||
|
||||
Creates a DAG with the given values with each entry labeled
|
||||
using the given tag. The list of values are placed _before_ each
|
||||
of the attribute names in `befores` and _after_ each of the
|
||||
attribute names in `afters`. For example
|
||||
Creates a DAG with the given values with each entry labeled using the given tag.
|
||||
The list of values are placed _before_ each of the attribute names in `befores`
|
||||
and _after_ each of the attribute names in `afters`. For example
|
||||
|
||||
```nix
|
||||
foo.bar =
|
||||
|
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
Language specific support means there is a combination of language specific
|
||||
plugins, `treesitter` support, `nvim-lspconfig` language servers, and `null-ls`
|
||||
integration. This gets you capabilities ranging from autocompletion to formatting
|
||||
to diagnostics. The following languages have sections under the `vim.languages`
|
||||
attribute.
|
||||
integration. This gets you capabilities ranging from autocompletion to
|
||||
formatting to diagnostics. The following languages have sections under the
|
||||
`vim.languages` attribute.
|
||||
|
||||
- Rust: [vim.languages.rust.enable](#opt-vim.languages.rust.enable)
|
||||
- Nix: [vim.languages.nix.enable](#opt-vim.languages.nix.enable)
|
||||
|
@ -20,8 +20,8 @@ attribute.
|
|||
- Lua: [vim.languages.lua.enable](#opt-vim.languages.lua.enable)
|
||||
- PHP: [vim.languages.php.enable](#opt-vim.languages.php.enable)
|
||||
|
||||
Adding support for more languages, and improving support for existing ones are great places
|
||||
where you can contribute with a PR.
|
||||
Adding support for more languages, and improving support for existing ones are
|
||||
great places where you can contribute with a PR.
|
||||
|
||||
```{=include=} sections
|
||||
languages/lsp.md
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
# LSP Custom Packages/Command {#sec-languages-custom-lsp-packages}
|
||||
|
||||
In any of the `opt.languages.<language>.lsp.package` options you can provide
|
||||
your own LSP package, or provide the command to launch the language server, as
|
||||
a list of strings. You can use this to skip automatic installation of a language
|
||||
your own LSP package, or provide the command to launch the language server, as a
|
||||
list of strings. You can use this to skip automatic installation of a language
|
||||
server, and instead use the one found in your `$PATH` during runtime, for
|
||||
example:
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue