feat: module system

.gitignore

@@ -12,6 +12,7 @@
 !.luarc.json
 !.editorconfig
 !stylua.toml
+!.styluaignore
 !.pre-commit-config.yaml
 !git-conventional-commits.yaml
 

.styluaignore

@@ -0,0 +1,2 @@
+testfiles/
+*.rockspec

TODO.md

@@ -1,7 +1,10 @@
 # TODO
 
 - [x] Add testing and linting to CI
-- [ ] Add iter spec
-- [ ] Add basic technical spec
-- [ ] Create the module system based on the spec (+ tests)
-- [ ] Create the first module (preamble) (+ tests)
+- [x] Add iter tests
+- [x] Add basic technical tests
+- [ ] Create the module system based on the spec
+- [ ] Create the first module (lsp)
+- [ ] Create the preamble module
+- [ ] Continue work on luaKITTENS
+- [ ] Continue work on luaKITTENS

docs/spec/0.1/functional.md

@@ -4,19 +4,21 @@
 
 * [Functional spec of cpp-tools.nvim](#functional-spec-of-cpp-toolsnvim)
 * [What is cpp-tools.nvim](#what-is-cpp-toolsnvim)
-  * [Main objectives](#main-objectives)
-  * [Installation](#installation)
-    * [Using Nix](#using-nix)
-    * [Using rocks.nvim](#using-rocksnvim)
-    * [Using lazy.nvim](#using-lazynvim)
-  * [Usage & configuration](#usage--configuration)
-  * [General info](#general-info)
+	* [Main objectives](#main-objectives)
+	* [Installation](#installation)
+		* [Using Nix](#using-nix)
+		* [Using rocks.nvim](#using-rocksnvim)
+		* [Using lazy.nvim](#using-lazynvim)
+	* [Usage & configuration](#usage--configuration)
+	* [General info](#general-info)
 * [Definitions](#definitions)
+* [Events](#events)
 * [Goals for *some* future release](#goals-for-some-future-release)
 * [Goals for this release](#goals-for-this-release)
 * [Goals for the **next** release](#goals-for-the-next-release)
 * [Non-goals for **any** release](#non-goals-for-any-release)
 * [Not sure if I'll ever implement these](#not-sure-if-ill-ever-implement-these)
+	* [Stash (For things that are not categorized or well though of yet)](#stash-for-things-that-are-not-categorized-or-well-though-of-yet)
 * [Known issues and questions](#known-issues-and-questions)
 
 <!-- vim-markdown-toc -->
@@ -98,6 +100,14 @@ vim.g.cpptools = {
 
 ...
 
+# Events
+
+The plugin defines and responds to the following autocommand events:
+- `CppToolsProject` - Fires once some time after neovim is opened and the current working directory is detected
+	to be a C++ project. It is used by some modules to start some stuff that is useful outside of the listed filetypes,
+		for example starting a language server on startup, to provide global workspace symbols and such out of the box.
+		If you don't want a certain module to respond to this event, you can set the `disable_project_event` option to `true`.
+
 # Goals for *some* future release
 
 # Goals for this release
@@ -120,9 +130,19 @@ vim.g.cpptools = {
 
 # Not sure if I'll ever implement these
 
+## Stash (For things that are not categorized or well though of yet)
+ - [ ] Find a way to reliably have access to the language server's features outside of C++ files.
+ - [ ] The problem with just attaching a client to any buffers will try to do things with the buffer - parse it, show diagnostics, etc.
+ - [ ] Some way to still provide go to definition even for semantic errors?
+ - [ ] Some way to easily check the versions of dependencies and general project info
+ - [ ] Better insert adding. If a symbol has been used manually and has a valid insert we insert a header lmao.
+
 - Linting:
   - [ ] Better integration with iwyu and such
 
+- Intelligence:
+	- [ ] Better lsp symbols with filtering and whatnot
+
 - Productivity:
   - [ ] Automatically define templates based on the contents
   - [ ] .as, .each, etc.

docs/spec/0.1/technical.md

@@ -1,6 +1,27 @@
 # Technical spec of cpp-tools.nvim
 
-## Automatic test runner
+# Table of Contents
+
+<!-- vim-markdown-toc GFM -->
+
+* [Technical spec of cpp-tools.nvim](#technical-spec-of-cpp-toolsnvim)
+* [Automatic test runner](#automatic-test-runner)
+* [The module system](#the-module-system)
+	* [Conventions](#conventions)
+	* [Types](#types)
+	* [Structure](#structure)
+* [luaKITTENS](#luakittens)
+
+<!-- vim-markdown-toc -->
+
+# Technical spec of cpp-tools.nvim
+
+> [!WARNING]
+> This is just a draft, some implementation is done already, but I may encounter
+> some issues and technical limitations later which may alter whatever is written here.
+
+
+# Automatic test runner
 
 Each module (lua module, not cpp-tools module) can define its tests by exposing a `__test` function.
 The function should contain ordinary busted tests.
@@ -15,3 +36,78 @@ It's called by busted (see `<root>/.busted`'s `_all.pattern` key) and receives i
 
 It then scans all lua files in `lua`, evaluates them and collects all that returned a table with the `__test` key,
 then calls each of the test functions with the context.
+
+# The module system
+
+TODO: Think what to do about config with possible side effects, dynamic binding and overriding config options for kickstart.
+
+## Conventions
+
+1. The types are denoted after `:` and use the [luaKITTENS annotation system](#luaKITTENS).
+2. `^` denotes a required field, dependent on some condition (e.g. the `required` - `default` relation).
+
+## Types
+
+1. The `kitty` type refers to a `string` that's a valid `kitten`, that is a valid `luaKITTENS` annotation.
+2. The `EventName` type refers to a `string` that's a valid neovim event name, see `:h events`
+
+## Structure
+
+The module system exists to be able to easily define all cpp-tools modules and ensure consistency and compatibility
+between all of them.
+
+Each module has its own namespace of form `('cpp-tools.%s'):format(name)` created. It's later used for events.
+
+Each valid cpp-tools module has the following structure:
+- **name**: `string` - The name of the module. (This is used for documentation generation as well)
+- **description**: `string` - Description of the module (This is used for documentation generation as well)
+- **config**: `{ [string]: ConfigEntry }?` - Configuration definition. `ConfigEntry` is defined as follows:
+	- **type**: `kitten` - A luaKITTENS annotation denoting the type of this config field.
+	- **validate**: `(fn | []any)?` - Either a function that takes in a value and checks if it's valid for the given field
+		or an array of valid values. A luaKITTENS type validation happens before this anyway.
+	- **required**^: `bool?` - Is this config field mandatory? (This field is not required if `default` is set, it implies `required = false`)
+	- **default**^: `any?` - A default value for this config field. Will error if `required = true`. (This field is not required if `required` is set to `false`)
+
+	- **example**^: `string` - An example of this field's usage. If `default` is set and this is not set, it will stringify the `default`'s value and use it instead. (This is used for documentation generation)
+	- **description**: `string` - The description for this config field. (This is used for documentation generation)
+
+	Each config additionally has the following **implicit** fields
+	- **enable**:
+		- **type** - `bool`
+		- **required** - `false`
+		- **default** - `false`
+		- **description** - `('Enables the %s module'):format(name)`
+
+	- **filetypes**:
+		- **type** - `[]string`
+		- **required** - `false`
+		- **default** - `{ 'c', 'cpp' }`
+		- **description** - `The filetypes this module should be loaded on.`
+
+	- **disable_project_event**:
+		- **type** - `bool`
+		- **required** - `false`
+		- **default** - `false`
+		- **description** - `Whether to disable the project event. It is fired once when neovim starts and a valid C/C++ project is detected in cwdc. Useful for starting up stuff that provides code intelligence outside of the given filetypes, for example global workspace symbols.`
+
+	If any module writes their own config fields with the same names, they will not get overridden.
+	This is the case for kickstart modules, which are loaded automatically.
+
+- **events**: `{ [EventName]: fn }` - The functions has to have the following signature: `fn(config, ctx): ModuleResult`
+	`config` is the evaluated config for this function, `ctx` is the execution context, which currently consists of:
+	<!-- TODO: ModuleResult -->
+	- **id**: `number` - Autocommand id
+	- **event**: `string` - Name of the triggered event
+	- **group**: `number` - Autocommand group id
+	- **buffer**: `number` - The buffer the event was fired in
+	- **filetype**: `string` - The filetype the the event fired in
+	- **file**: `string` - The filename in which the event filed
+	- **data**: `any` - Arbitrary data passed from `nvim_exec_autocmds()`
+
+- **init**: `fn` - A function called once at the beginning if the module is enabled and the user visited one of the filetypes once.
+	The signature is the same as the one of `events` fn.
+
+# luaKITTENS
+<!-- TODO: --> Proper spec
+
+For now consult the `lua/cpp-tools/lib/luakittens/parser` file, the `__test` function and the `only_parse()` function.

ftplugin/cpp.lua

@@ -1 +1,4 @@
-require('cpp-tools').setup()
+-- TODO: Version check here probably
+if vim.tbl_get(vim.g, 'cpp_tools', 'enable') == true then
+	require('cpp-tools').setup()
+end

lua/cpp-tools/auto_test_runner/auto_test_runner.lua

@@ -2,7 +2,7 @@
 --- This file scans all the requirable `lua/` files from here
 --- and runs their __test functions with busted test context.
 
-local current_filename = debug.getinfo(1).source:match('([%w_%.]+)$')
+local current_filename = require('cpp-tools.lib.paths').current_filename()
 local testfiles_dir = vim.fs.root(0, 'testfiles') .. '/testfiles'
 
 local function project_lua_files(path, type)

lua/cpp-tools/auto_test_runner/test.lua

@@ -8,7 +8,6 @@ function M.__test(testfiles_dir)
 	describe('auto test runner', function()
 		it('returns a proper testfiles dir', function()
 			local file = testfiles_dir .. '/auto_test_runner/test.txt'
-			print(file)
 			local f, msg = io.open(file)
 
 			if not f then