Skip to content

Latest commit

 

History

History
74 lines (53 loc) · 2.42 KB

File metadata and controls

74 lines (53 loc) · 2.42 KB

Contributing to neomd

Thanks for your interest! This is a small project — keep changes focused and minimal.

Prerequisites

  • Go 1.22+
  • A terminal (you're a neomd user, so... probably covered)

Quick start

git clone https://github.com/sspaeti/neomd
cd neomd
make build      # compile to ./neomd
make test       # run unit tests
./neomd         # try it out

Before opening a PR

make fmt          # format Go source (gofmt)
make fmt-check    # verify formatting (CI runs this too)
make vet          # go vet
make test         # unit tests

If any of the above fails, fix it before pushing.

Code style

  • Formatter: gofmt (ships with Go — no extra tooling required).
  • Keep diffs minimal. Fix the specific thing; don't refactor adjacent code.
  • Keybindings: edit internal/ui/keys.go only — docs/keybindings.md is auto-generated by make docs (runs on every build). Never hand-edit the markdown table.
  • Compose buffer markers: use plain-text markers like [attach] /path, never HTML comments (treesitter hides them in the compose buffer).

See CLAUDE.md for deeper architectural notes (state machine, MIME structure, IMAP quirks).

Neovim setup (recommended)

Since neomd is a Neovim-flavored email client, you're probably already in Neovim. The simplest format-on-save uses gopls (the Go LSP) — no extra plugin needed:

-- gopls config (e.g. via nvim-lspconfig)
require("lspconfig").gopls.setup({})

-- Format Go files on save via gopls (uses gofmt)
vim.api.nvim_create_autocmd("BufWritePre", {
  pattern = "*.go",
  callback = function(args)
    vim.lsp.buf.format({
      bufnr = args.buf,
      filter = function(client) return client.name == "gopls" end,
      timeout_ms = 2000,
    })
  end,
})

Install gopls itself with go install golang.org/x/tools/gopls@latest.

Alternative: conform.nvim configured with formatters_by_ft = { go = { "gofmt" } } — useful if you want a single formatter plugin across multiple languages.

PR guidelines

  • One topic per PR.
  • Describe why, not just what — the diff already shows what changed.
  • Include a quick test plan (what you tried, what you expect).
  • If you touch keybindings, MIME building, IMAP calls, or the screener, mention it explicitly — those are the load-bearing parts.

Questions?

Open an issue or start a discussion on GitHub. Happy hacking.