`pay-respects` followed a very stupid approach ---or better said, *Keep It Simple, Stupid*--- when it comes to implementing the module / plugin system:
- Modules interacts with core program by passing **messages through processes**. In other words, we are sending necessary information to the module, so it can return the required suggestion.
- This approach is the most extendable way, as it has the least amount of limitations compared to:
- Dynamic libraries (Safe): Requires the module to be compiled in the same compiler version as the core, which also limits the language available
- FFI (Unsafe): Requires overloading of dynamic libraries, limits to C types, and not extendable as it's overloading a library instead of appending
- Embedding a runtime: Unnecessary binary sizes if never used
-`pay-respects` takes the message passing approach as its core is blazing fast without observable delay so having a small overhead is acceptable. This allows:
- **Modules in any language**: Regardless of compiled binary or interpreted scripts, just make them executable and that's a module!
- **Extendable**: As many modules as you want
- **Performance or ease? Both!**: Write in a compiled language if it's something computational heavy, or just use a shell script as module right away
## Creating a Module
There are 2 types of modules:
- **Standard module**: Will always run to retrieve suggestions
Priority is used to retrieve suggestions in a specific order by an [unstable sort](https://doc.rust-lang.org/std/primitive.slice.html#method.sort_unstable) (although they will always be after compile-time matches). Default modules have a priority of `100`.
If exposing modules in `PATH` annoys you, you can set the `_PR_LIB` environment variable to specify directories to find the modules, separated by `:` (analogous to `PATH`). The variable can be set either runtime or compile-time.
This is not the default as there is no general way to know its value and depends on distribution (`/usr/lib`, `/usr/libexec`, `/data/data/com.termux/files/usr/libexec`, etc.). System programs usually have a hard-coded path looking for `lib`. If you are a package maintainer for a distribution, setting this value when compiling, so it fits into your distribution standard.
If you installed the module with `cargo install`, the binary will be placed in `bin` subdirectory under Cargo's home which should be in the `PATH` anyway. Cargo has no option to place in subdirectories with other names.
The following snippet is what I have included into Arch Linux's package with workflows binaries, adding a `_PR_LIB` declaration along with initialization. The script is `/usr/bin/pay-respects` and the actual executable is located somewhere else.
