Skip to content

Latest commit

 

History

History
31 lines (26 loc) · 2.26 KB

File metadata and controls

31 lines (26 loc) · 2.26 KB

Repository Guidelines

Project Structure & Module Organization

  • lib/roded holds the core editor classes (Application, Buffer, Window, StatusBar, Minibuffer, Event/Command, Logging); frontends live in lib/roded/frontends (currently curses).
  • Binaries: bin/roded entrypoint, bin/console for IRB sandboxing, bin/setup for bootstrapping.
  • Tests sit in spec with shared config in spec/spec_helper.rb; default Rake task runs tests and lint.
  • Packaging/metadata lives in roded.gemspec; docs in docs/; built gems accumulate in pkg/.

Build, Test, and Development Commands

  • bin/setup installs Bundler dependencies.
  • bundle exec rake runs specs and RuboCop (default task).
  • bundle exec rspec runs the test suite; .rspec_status tracks failures between runs.
  • bundle exec rubocop enforces style (TargetRubyVersion 3.4, double-quoted strings).
  • bundle exec rake install builds and installs the gem locally; bin/roded launches the curses UI (requires terminal curses support).

Coding Style & Naming Conventions

  • Ruby 3.4 syntax; prefer double-quoted strings; omit # frozen_string_literal: true headers.
  • One top-level class/module per file under lib/roded, matching snake_case filenames.
  • Class/module names PascalCase; methods/variables snake_case; constants SCREAMING_SNAKE_CASE.
  • Keep concurrency interactions thread-safe (Application uses Queue + threads; curses frontend reads input via IO.select).

Testing Guidelines

  • Framework: RSpec; place specs alongside features in spec/*_spec.rb.
  • Name examples with behavior statements (it "renders buffer top line"), avoiding brittle curses-terminal assertions.
  • Cover command routing and buffer mutations when adding features; use test doubles for frontends when possible.

Commit & Pull Request Guidelines

  • Commit messages short, imperative, and scoped (Add cursor redraw command); reserve --wip-- [skip ci] only for temporary checkpoints.
  • Rebase or squash noisy WIP commits before review; link issues in the message or PR description when relevant.
  • PRs should describe intent, testing performed (bundle exec rake, manual TUI check), and any UI changes (screenshots/recordings welcome).
  • Flag breaking changes (keybindings, file I/O) prominently and update docs/README if behavior shifts.