Contributing Guide

Thanks for wanting to help out with nvim-orgmode, we appreciate the effort!

• Reporting Bugs/Features
• Documentation
• Development
  • Philosophy
  • Local dev
  • Code
    • Tests
    • Parser

Reporting Bugs/Features

📣 Please always make a quick search in our issue-tracker before reporting anything. If the bug/feature has already been reported, continue the conversation on the existing issue.

We distinguish between core (part of orgmode) and non-core features. The former will be prioritized. Bugs get the highest priority.

If you're reporting a core feature, please be sure to provide a link that describes it. There are several places where features could be documented, have a look at these resources. The more info you provide the better!

Documentation

If you spot something missing in our docs, don't hesitate making a PR. The wiki can be edited freely.

Development

Philosophy

We try to mimic the behavior of Emacs Orgmode as closely as possible. Variable names follow the same naming convention as in Emacs Orgmode, except that they are in snake_case instead of kebab-case.

Example: org-agenda-files in Emacs is org_agenda_files in nvim-orgmode.

Local dev

Requirements:

• StyLua - For formatting

To set up local development, run make setup_dev. This will add a pre-commit hook that will auto format all files before committing them. You can always manually format all files with make format command

Code

If you prefer working on an issue that has been reported, please leave a comment voicing your interest.

Please document any new code you add with emmylua annotations. Feel free to add annotations/docs to any existing functions integral to your PR that are missing them.

Tests

To run tests run make test in the nvim-orgmode directory:

make test

To run a specific test you can set a FILE environment variable to a specific spec you want to test. Example:

make test FILE=./tests/plenary/api/api_spec.lua

Parser

Parsing is done via builtin treesitter parser and the tree-sitter-org grammar.

Commits

Ensure that you follow the Conventional Commits specification (e.g., feat: add new feature, fix: correct bug, docs: update documentation).