Merge pull request #591 from NotAShelf/docs-touchup

treewide: general cleanup in docs and contribution exp.

.editorconfig

@@ -14,7 +14,7 @@ indent_style = space
 indent_size = 2
 trim_trailing_whitespace = false
 
-[*.{js,nix,yml,yaml}]
+[*.{js,json,nix,yml,yaml}]
 indent_style = space
 indent_size = 2
 tab_width = 2

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -7,14 +7,17 @@ or dependency in this section.
 If your pull request aims to fix an open issue or a please bug, please also link the relevant issue
 below this line. You may attach an issue to your pull request with `Fixes #<issue number>` outside
 this comment, and it will be closed when your pull request is merged.
+
+A developer package template is provided in flake/develop.nix. If working on a module, you may use
+it to test your changes with minimal dependency changes.
 -->
 
 ## Sanity Checking
 
 <!--
 Please check all that apply. As before, this section is not a hard requirement but checklists with more checked
-items are likely to be merged faster. You may save some time in maintainer review by performing self-reviews here
-before submitting your pull request.
+items are likely to be merged faster. You may save some time in maintainer reviews by performing self-reviews
+here before submitting your pull request.
 
 If your pull request includes any change or unexpected behaviour not covered below, please do make sure to include
 it above in your description.
@@ -22,9 +25,11 @@ it above in your description.
 
 [editorconfig]: https://editorconfig.org
 [changelog]: https://github.com/NotAShelf/nvf/tree/main/docs/release-notes
+[hacking nvf]: https://notashelf.github.io/nvf/index.xhtml#sec-guidelines
 
 - [ ] I have updated the [changelog] as per my changes
 - [ ] I have tested, and self-reviewed my code
+- [ ] My changes fit guidelines found in [hacking nvf]
 - Style and consistency
   - [ ] I ran **Alejandra** to format my code (`nix fmt`)
   - [ ] My code conforms to the [editorconfig] configuration of the project
@@ -34,9 +39,10 @@ it above in your description.
   - [ ] I have added a section in the manual
   - [ ] _(For breaking changes)_ I have included a migration guide
 - Package(s) built:
-  - [ ] `.#nix` (default package)
+  - [ ] `.#nix` _(default package)_
   - [ ] `.#maximal`
-  - [ ] `.#docs-html` (manual, must build)
+  - [ ] `.#docs-html` _(manual, must build)_
+  - [ ] `.#docs-linkcheck` _(optional, please build if adding links)_
 - Tested on platform(s)
   - [ ] `x86_64-linux`
   - [ ] `aarch64-linux`
@@ -46,7 +52,8 @@ it above in your description.
 <!--
 If your changes touch upon a portion of the codebase that you do not understand well, please make sure to consult
 the maintainers on your changes. In most cases, making an issue before creating your PR will help you avoid duplicate
-efforts in the long run.
+efforts in the long run. `git blame` might help you find out who is the "author" or the "maintainer" of a current
+module by showing who worked on it the most.
 -->
 
 ---

.github/README.md

@@ -50,6 +50,7 @@
 [Contribute]: #contributing
 [FAQ]: #frequently-asked-questions
 [Credits]: #credits
+[License]: #license
 
 **[<kbd><br> Features <br></kbd>][Features]**
 **[<kbd><br> Get Started <br></kbd>][Get Started]**
@@ -67,6 +68,10 @@
 [standalone]: https://notashelf.github.io/nvf/index.xhtml#ch-standalone-installation
 [NixOS module]: https://notashelf.github.io/nvf/index.xhtml#ch-standalone-nixos
 [Home-Manager module]: https://notashelf.github.io/nvf/index.xhtml#ch-standalone-hm
+[release notes]: https://notashelf.github.io/nvf/release-notes.html
+[discussions tab]: https://github.com/notashelf/nvf/discussions
+[FAQ section]: #frequently-asked-questions
+[DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph
 
 - **Simple**: One language to rule them all! Use Nix to configure everything,
   with optional Lua support for robust configurability!
@@ -79,11 +84,31 @@
   customizable through the Nix module system.
   - Not comfortable with a full-nix config or want to bring your Lua config? You
     can do just that, no unnecessary restrictions.
-  - Lazyloading? We got it! Lazyload both internal and external plugins at will.
+  - Lazyloading 💤? We got it! Lazyload both internal and external plugins at
+    will.
+  - nvf allows _ordering configuration bits_ using [DAG] (_Directed acyclic
+    graph_)s. It has never been easier to construct an editor configuration
+    deterministically!
+  - nvf exposes everything you need to avoid a vendor lock-in. Which means you
+    can add new modules, plugins and so on without relying on us adding a module
+    for them! Though, of course, feel free to request them.
+    - Use plugins from anywhere. Inputs, npins, nixpkgs... You name it.
+    - Add your own modules, with ease. It's all built-in!
 - **Well-documented**: Documentation is priority. You will _never_ face
   undocumented, obscure behaviour.
+  - Changes, breaking or otherwise, will be communicated in the [release notes]
+  - Refer to the [FAQ section] for answers to common questions.
+    - Your question not there? Head to the to the [discussions tab]!
 - **Idiomatic**: nvf does things ✨ _the right way_ ✨ - the codebase is, and
   will, remain maintainable for myself and any contributors.
+- **Community-Led**: we would like nvf to be fully capable of accomplishing what
+  you really want it to do. If you have a use case that is not made possible by
+  nvf, please open an issue (or a pull request!)
+  - Your feedback is more than welcome! Feedback is what _drives_ nvf forward.
+    If you have anything to say, or ask, please let us know.
+  - Pull requests are _always_ welcome. If you think the project can benefit
+    from something you did locally, but are not quite sure how to upstream,
+    please feel free to contact us! We'll help you get it done.
 
 ## Get Started
 
@@ -173,36 +198,49 @@ fix.
 [list of open pull requests]: https://github.com/NotAShelf/nvf/pulls
 
 **Q**: What platforms are supported?
-<br/> **A**: nvf actively supports **Linux and Darwin** platforms using
-standalone Nix, NixOS or Home-Manager. Please take a look at the [nvf manual]
-for available installation instructions.
+
+**A**: nvf actively supports **Linux and Darwin** platforms using standalone
+Nix, NixOS or Home-Manager. Please take a look at the [nvf manual] for available
+installation instructions.
 
 **Q**: Can you add _X_?
-<br/> **A**: Maybe! It is not one of our goals to support each and every Neovim
+
+**A**: Maybe! It is not one of our goals to support each and every Neovim
 plugin, however, I am always open to new modules and plugin setup additions to
 **nvf**. Use the appropriate [issue template] and I will consider a module
 addition. As mentioned before, pull requests to add new features are also
 welcome.
 
 **Q**: A plugin I need is not available in **nvf**. What to do?
-<br/> **A**: **nvf** exposes several APIs for you to be able to add your own
-plugin configurations! Please see the documentation on how you may do this.
+
+**A**: **nvf** exposes several APIs for you to be able to add your own plugin
+configurations! Please see the documentation on how you may do this.
 
 **Q**: Main branch is awfully silent, is the project dead?
-<br/> **A**: No! Sometimes we branch out (e.g. `v0.6`) to avoid breaking
-userspace and work in a separate branch until we make sure the new additions are
-implemented in the most comfortable way possible for the end user. If you have
-not noticed any activity on the main branch, consider taking a look at the
+
+**A**: No! Sometimes we branch out (e.g. `v0.6`) to avoid breaking userspace and
+work in a separate branch until we make sure the new additions are implemented
+in the most comfortable way possible for the end user. If you have not noticed
+any activity on the main branch, consider taking a look at the
 [list of branches] or the [list of open pull requests]. You may also consider
 _testing_ those release branches to get access to new features ahead of time and
 better prepare to breaking changes.
 
 **Q**: Will you support non-flake installations?
-<br/> **A**: Quite possibly. **nvf** started as "neovim-flake", which does mean
-it is and will remain flakes-first but we might consider non-flakes
-compatibility. Though keep in mind that **nvf** under non-flake environments
-would lose customizability of plugin inputs, which is one of our primary
-features.
+
+**A**: Quite possibly. **nvf** started as "neovim-flake", which does mean it is
+and will remain flakes-first but we might consider non-flakes compatibility.
+Though keep in mind that **nvf** under non-flake environments would lose
+customizability of plugin inputs, which is one of our primary features.
+
+**Q**: I prefer working with Lua, can I use nvf as a plugin manager while I use
+an imperative path (e.g., `~/.config/nvim`) for my Neovim configuration instead
+of a configuration generated from Nix?
+
+**A**: Yes! Add `"~/.config.nvim"` to `vim.additionalRuntimePaths = [ ... ]` and
+any plugins you want to load to `vim.startPlugins`. This will load your
+configuration from `~/.config/nvim`. You may still use `vim.*` to modify
+Neovim's behaviour with Nix.
 
 ## Credits
 
@@ -245,7 +283,7 @@ and everyone who has submitted issues or pull requests!
 
 ### Inspiration
 
-This configuration borrows from and is based on a few other configurations,
+This configuration borrows from, and is based on a few other configurations,
 including:
 
 - [@jordanisaacs's](https://github.com/jordanisaacs)

configuration.nix

@@ -1,6 +1,7 @@
 # This is the sample configuration for nvf, aiming to give you a feel of the default options
-# while certain plugins are enabled. While it may act as one, this is not an overview of nvf's
-# module options. To find a complete overview of nvf's options and examples, visit the manual.
+# while certain plugins are enabled. While it may partially act as one, this is *not* quite
+# an overview of nvf's module options. To find a complete and curated list of nvf module
+# options, examples, instruction tutorials and more; please visit the online manual.
 # https://notashelf.github.io/nvf/options.html
 isMaximal: {
   config.vim = {

docs/manual.nix

@@ -102,7 +102,7 @@ in
         --script script/anchor-use.js \
         --script script/anchor-min.js \
         --script script/search.js \
-        --toc-depth 2 \
+        --toc-depth 1 \
         --section-toc-depth 1 \
         manual.md \
         "$dest/index.xhtml"

docs/manual/options.md

@@ -1,9 +1,13 @@
-# Neovim Flake Configuration Options {#ch-options}
+# nvf Configuration Options {#ch-options}
 
 Below are the module options provided by nvf, in no particular order. Most
 options will include useful comments, warnings or setup tips on how a module
 option is meant to be used as well as examples in complex cases.
 
+An offline version of this page is bundled with nvf as a part of the manpages
+which you can access with `man 5 nvf`. Please us know if you believe any of the
+options below are missing useful examples.
+
 <!--
 In the manual, individual options may be referenced in Hyperlinks as follows:
 [](#opt-vim.*) If changing the prefix here, do keep in mind the #opt- suffix will have

docs/manual/tips.md

@@ -1,6 +1,7 @@
 # Helpful Tips {#ch-helpful-tips}
 
 ```{=include=} chapters
+tips/pure-lua-config.md
 tips/debugging-nvf.md
 tips/offline-docs.md
 ```

docs/manual/tips/debugging-nvf.md

@@ -17,3 +17,9 @@ nvf-print-config | bat --language=lua
 ```
 
 Alternatively, `cat` or `less` may also be used.
+
+## Accessing `neovimConfig` {#sec-accessing-config}
+
+It is also possible to access the configuration for the wrapped package. The
+_built_ Neovim package will contain a `neovimConfig` attribute in its
+`passthru`.

docs/manual/tips/pure-lua-config.md

@@ -0,0 +1,117 @@
+# Pure Lua Configuration {#sec-pure-lua-config}
+
+We recognize that you might not always want to configure your setup purely in
+Nix, sometimes doing things in Lua is simply the "superior" option. In such a
+case you might want to configure your Neovim instance using Lua, and nothing but
+Lua. It is also possible to mix Lua and Nix configurations.
+
+Pure Lua or hybrid Lua/Nix configurations can be achieved in two different ways.
+_Purely_, by modifying Neovim's runtime directory or _impurely_ by placing Lua
+configuration in a directory found in `$HOME`. For your convenience, this
+section will document both methods as they can be used.
+
+## Pure Runtime Directory {#sec-pure-nvf-runtime}
+
+As of 0.6, nvf allows you to modify Neovim's runtime path to suit your needs.
+One of the ways the new runtime option is to add a configuration **located
+relative to your `flake.nix`**, which must be version controlled in pure flakes
+manner.
+
+```nix
+{
+  # Let us assume we are in the repository root, i.e., the same directory as the
+  # flake.nix. For the sake of the argument, we will assume that the Neovim lua
+  # configuration is in a nvim/ directory relative to flake.nix.
+  vim = {
+    additionalRuntimeDirectories = [
+      # This will be added to Neovim's runtime paths. Conceptually, this behaves
+      # very similarly to ~/.config/nvim but you may not place a top-level
+      # init.lua to be able to require it directly.
+      ./nvim
+    ];
+  };
+}
+```
+
+This will add the `nvim` directory, or rather, the _store path_ that will be
+realised after your flake gets copied to the Nix store, to Neovim's runtime
+directory. You may now create a `lua/myconfig` directory within this nvim
+directory, and call it with [](#opt-vim.luaConfigRC).
+
+```nix
+{pkgs, ...}: {
+  vim = {
+    additionalRuntimeDirectories = [
+      # You can list more than one file here.
+      ./nvim-custom-1
+
+      # To make sure list items are ordered, use lib.mkBefore or lib.mkAfter
+      # Simply placing list items in a given order will **not** ensure that
+      # this list  will be deterministic.
+      ./nvim-custom-2
+    ];
+
+    startPlugins = [pkgs.vimPlugins.gitsigns];
+
+    # Neovim supports in-line syntax highlighting for multi-line strings.
+    # Simply place the filetype in a /* comment */ before the line.
+    luaConfigRC.myconfig = /* lua */ ''
+      -- Call the Lua module from ./nvim/lua/myconfig
+      require("myconfig")
+
+      -- Any additional Lua configuration that you might want *after* your own
+      -- configuration. For example, a plugin setup call.
+      require('gitsigns').setup({})
+    '';
+  };
+}
+```
+
+## Impure Absolute Directory {#sec-impure-absolute-dir}
+
+[Neovim 0.9]: https://github.com/neovim/neovim/pull/22128
+
+As of [Neovim 0.9], {var}`$NVIM_APPNAME` is a variable expected by Neovim to
+decide on the configuration directory. nvf sets this variable as `"nvf"`,
+meaning `~/.config/nvf` will be regarded as _the_ configuration directory by
+Neovim, similar to how `~/.config/nvim` behaves in regular installations. This
+allows some degree of Lua configuration, backed by our low-level wrapper
+[mnw](https://github.com/Gerg-L/mnw). Creating a `lua/` directory located in
+`$NVIM_APPNAME` ("nvf" by default) and placing your configuration in, e.g.,
+`~/.config/nvf/lua/myconfig` will allow you to `require` it as a part of the Lua
+module system through nvf's module system.
+
+Let's assume your `~/.config/nvf/lua/myconfig/init.lua` consists of the
+following:
+
+```lua
+-- init.lua
+vim.keymap.set("n", " ", "<Nop>", { silent = true, remap = false })
+vim.g.mapleader = " "
+```
+
+The following Nix configuration via [](#opt-vim.luaConfigRC) will allow loading
+this
+
+```nix
+{
+  # The attribute name "myconfig-dir" here is arbitrary. It is required to be
+  # a *named* attribute by the DAG system, but the name is entirely up to you.
+  vim.luaConfigRC.myconfig-dir = ''
+    require("myconfig")
+
+    -- Any additional Lua
+  '';
+}
+```
+
+[DAG system]: https://notashelf.github.io/nvf/index.xhtml#ch-using-dags
+
+After you load your custom configuration, you may use an `init.lua` located in
+your custom configuration directory to configure Neovim exactly as you would
+without a wrapper like nvf. If you want to place your `require` call in a
+specific position (i.e., before or after options you set in nvf) the
+[DAG system] will let you place your configuration in a location of your
+choosing.
+
+[top-level DAG system]: https://notashelf.github.io/nvf/index.xhtml#ch-vim-luaconfigrc

flake.nix

@@ -17,6 +17,8 @@
       # «https://github.com/nix-systems/nix-systems»
       systems = import inputs.systems;
       imports = [
+        ./flake/templates
+
         ./flake/apps.nix
         ./flake/legacyPackages.nix
         ./flake/overlays.nix

flake/packages.nix

@@ -19,9 +19,11 @@
       in
         pkgs.testers.lycheeLinkCheck {
           inherit site;
+
           remap = {
             "https://notashelf.github.io/nvf/" = site;
           };
+
           extraConfig = {
             exclude = [];
             include_mail = true;
@@ -29,43 +31,39 @@
           };
         };
 
-      # Build and open the built manual in your system browser
-      docs-html-wrapped = pkgs.writeScriptBin "docs-html-wrapped" ''
-        #!${pkgs.stdenv.shell}
-        # use xdg-open to open the docs in the browser
-        ${pkgs.xdg-utils}/bin/xdg-open ${docs.manual.html}
-      '';
+      # Helper utility for building the HTML manual and opening it in the
+      # browser with $BROWSER or using xdg-open as a fallback tool.
+      # Adapted from Home-Manager, available under the MIT license.
+      docs-html-wrapped = let
+        xdg-open = lib.getExe' pkgs.xdg-utils "xdg-open";
+        docs-html = docs.manual.html + /share/doc/nvf;
+      in
+        pkgs.writeShellScriptBin "docs-html-wrapped" ''
+          set -euo pipefail
+
+          if [[ ! -v BROWSER || -z $BROWSER ]]; then
+            for candidate in xdg-open open w3m; do
+            BROWSER="$(type -P $candidate || true)"
+              if [[ -x $BROWSER ]]; then
+                break;
+              fi
+            done
+          fi
+
+          if [[ ! -v BROWSER || -z $BROWSER ]]; then
+            echo "$0: unable to start a web browser; please set \$BROWSER"
+            echo "$0: Trying xdg-open as a fallback"
+            ${xdg-open} ${docs-html}/index.xhtml
+          else
+            echo "\$BROWSER is set. Attempting to open manual"
+            exec "$BROWSER" "${docs-html}/index.xhtml"
+          fi
+        '';
 
       # Exposed neovim configurations
       nix = config.legacyPackages.neovim-nix;
       maximal = config.legacyPackages.neovim-maximal;
       default = config.legacyPackages.neovim-nix;
-
-      # Published docker images
-      docker-nix = let
-        inherit (pkgs) bash gitFull buildEnv;
-        inherit (config.legacyPackages) neovim-nix;
-      in
-        pkgs.dockerTools.buildImage {
-          name = "nvf";
-          tag = "latest";
-
-          copyToRoot = buildEnv {
-            name = "neovim-root";
-            pathsToLink = ["/bin"];
-            paths = [
-              neovim-nix
-              gitFull
-              bash
-            ];
-          };
-
-          config = {
-            Cmd = ["${neovim-nix}/bin/nvim"];
-            WorkingDir = "/home/neovim/demo";
-            Volumes = {"/home/neovim/demo" = {};};
-          };
-        };
     };
   };
 }

flake/templates/default.nix

@@ -0,0 +1,17 @@
+{
+  flake.templates = {
+    standalone = {
+      path = ./standalone;
+      description = "Standalone flake template for nvf";
+      welcomeText = ''
+        Template flake.nix has been created in flake.nix!
+
+        Note that this is a very basic example to bootstrap nvf for you. Please edit your
+        configuration as described in the nvf manual before using this template. The
+        configured packages will be ran with 'nix run .' or 'nix run .#neovimConfigured'
+
+        Happy editing!
+      '';
+    };
+  };
+}

flake/templates/standalone/flake.nix

@@ -0,0 +1,64 @@
+{
+  inputs = {
+    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
+    nvf.url = "github:notashelf/nvf";
+  };
+
+  outputs = {
+    self,
+    nixpkgs,
+    ...
+  } @ inputs: let
+    # An abstraction over systems to easily provide the same package
+    # for multiple systems. This is preferable to abstraction libraries.
+    forEachSystem = nixpkgs.lib.genAttrs ["x86_64-linux"];
+  in {
+    packages = forEachSystem (system: let
+      pkgs = inputs.nixpkgs.legacyPackages.${system};
+
+      # A module to be evaluated via lib.evalModules inside nvf's module system.
+      # All options supported by nvf will go under config.vim to create the final
+      # wrapped package. You may also add some new *options* under options.* to
+      # expand the module system.
+      configModule = {
+        # You may browse available options for nvf on the online manual. Please see
+        # <https://notashelf.github.io/nvf/options.html>
+        config.vim = {
+          theme.enable = true;
+
+          # Language support and automatic configuration of companion plugins.
+          # Note that enabling, e.g., languages.<lang>.diagnostics will automatically
+          # enable top-level options such as enableLSP or enableExtraDiagnostics as
+          # they are needed.
+          languages = {
+            enableLSP = true;
+            enableFormat = true;
+            enableTreesitter = true;
+            enableExtraDiagnostics = true;
+
+            # Nix language and diagnostics.
+            nix.enable = true;
+          };
+        };
+      };
+
+      # Evaluate any and all modules to create the wrapped Neovim package.
+      neovimConfigured = inputs.nvf.lib.neovimConfiguration {
+        inherit pkgs;
+
+        modules = [
+          # Configuration module to be imported. You may define multiple modules
+          # or even import them from other files (e.g., ./modules/lsp.nix) to
+          # better modularize your configuration.
+          configModule
+        ];
+      };
+    in {
+      # Packages to be exposed under packages.<system>. Those can accessed
+      # directly from package outputs in other flakes if this flake is added
+      # as an input. You may run those packages with 'nix run .#<package>'
+      default = self.packages.${system}.neovim;
+      neovimConfigured = neovimConfigured.neovim;
+    });
+  };
+}

lib/dag.nix

@@ -24,7 +24,7 @@ in {
   entryAfter, and entryBefore to a topologically sorted list of
   entries.
 
-  Internally this function uses the `toposort` function in
+  Internally this function uses the `topoSort` function in
   `<nixpkgs/lib/lists.nix>` and its value is accordingly.
 
   Specifically, the result on success is
@@ -136,16 +136,26 @@ in {
   entriesAfter = tag: entriesBetween tag [];
   entriesBefore = tag: before: entriesBetween tag before [];
 
-  # mkLuarcSection and mkVimrcSection take a section DAG
-  # and return a string containing a comment to identify
+  # mkLuarcSection takes a section DAG, containing 'name' and 'data' fields
+  # then returns a string containing a comment to identify the section, and
+  # the data contained within the section.
   # the section, and the data contained within the section
   #
-  # all operations are done without any modifications
-  # to the inputted section data
-  mkLuarcSection = section: ''
-    -- SECTION: ${section.name}
-    ${section.data}
-  '';
+  # All operations are done without any modifications to the inputted section
+  # data, but if a non-string is passed to name or data, then it will try to
+  # coerce it into a string, which may fail. Setting data to "" or null will
+  # return an empty string.
+  #
+  # section.data should never be null, though taking 'null' as a value that
+  # can "clear" the DAG might come in handy for filtering sections more easily.
+  # Or perhaps simply unsetting them from an user perspective.
+  mkLuarcSection = section:
+    if section.data == "" || section.data == null
+    then ""
+    else ''
+      -- SECTION: ${section.name}
+      ${section.data}
+    '';
 
   resolveDag = {
     name,

release.json

@@ -1,4 +1,4 @@
 {
-	"release": "v0.8",
-	"isReleaseBranch": false
+  "release": "v0.8",
+  "isReleaseBranch": false
 }