Skip to content

Add --repeat recurrence support for add/edit (closes #104) - #109

Open
rameshbaskaran wants to merge 1 commit into
keith:mainfrom
rameshbaskaran:feature/repeat-recurrence-104
Open

Add --repeat recurrence support for add/edit (closes #104)#109
rameshbaskaran wants to merge 1 commit into
keith:mainfrom
rameshbaskaran:feature/repeat-recurrence-104

Conversation

@rameshbaskaran

Copy link
Copy Markdown
Contributor

Closes #104.

What

Adds EKRecurrenceRule-backed recurrence support:

  • reminders add <list> <reminder> --repeat daily|weekly|monthly|yearly
  • --repeat-interval N to repeat every N units instead of every 1 (default 1), e.g. --repeat-interval 2 --repeat weekly for fortnightly.
  • --repeat-until <date> to set a recurrence end date; omitting it repeats forever, matching Reminders.app's own default.
  • reminders edit <list> <index> --repeat ... replaces an existing repeat rule; --clear-repeat removes it entirely.
  • --format json output now includes recurrence, recurrenceInterval, and recurrenceEnd fields when present.

Why hourly is rejected rather than supported

EKRecurrenceFrequency has no hourly case -- Reminders.app's own UI doesn't expose hourly repeat either. Rather than silently degrade --repeat hourly to a daily rule (which would be a functional lie about what was actually configured), it's rejected at validate() with an explanation. Happy to change this if there's a preferred approach (e.g. a documented "hourly" alias that installs a daily rule with a note), but silent degradation felt worse than an explicit error.

Testing

Tested live against real Reminders.app data on macOS: add with daily/weekly/monthly + custom interval + end date, edit to both replace and clear a repeat rule, hourly correctly rejected with the explanatory error, --repeat-interval/--repeat-until correctly rejected when used without --repeat, and the --repeat + --clear-repeat conflict correctly rejected.

Added Tests/RemindersTests/RecurrenceTests.swift covering the frequency mapping, interval, end-date, and representability logic at the unit level.

Note on swift test locally: my dev machine currently only has Command Line Tools installed (no full Xcode), so swift test can't link XCTest here (xcrun --find xctest fails) -- this affects the pre-existing NaturalLanguageTests.swift identically, confirming it's a local environment gap and not something this PR introduces. swift build succeeds cleanly. The new test file is plain XCTest and should run normally in CI or on a machine with full Xcode -- I'm installing full Xcode now and will confirm swift test passes once that's done, but wanted to open this for review in the meantime rather than block on it.

Backward compatibility

All new flags are optional with sensible defaults (--repeat-interval defaults to 1, omitting --repeat/--repeat-until leaves existing behavior untouched). No changes to existing flag behavior or output format for reminders without a recurrence rule.

Implements EKRecurrenceRule-backed recurrence, requested in keith#104:

- `reminders add <list> <reminder> --repeat daily|weekly|monthly|yearly`
- `--repeat-interval N` to repeat every N units instead of every 1
  (default 1), e.g. `--repeat-interval 2 --repeat weekly` for
  fortnightly.
- `--repeat-until <date>` to set a recurrence end date; omitting it
  repeats forever, matching Reminders.app's own default.
- `reminders edit <list> <index> --repeat ...` replaces an existing
  repeat rule; `--clear-repeat` removes it entirely.
- JSON output (`--format json`) now includes `recurrence`,
  `recurrenceInterval`, and `recurrenceEnd` fields when a reminder has
  a recurrence rule, so scripts consuming `reminders show --format
  json` can see it.

`hourly` is intentionally rejected with a clear validation error
rather than silently degrading to a daily rule: EventKit's
`EKRecurrenceFrequency` has no hourly case (Reminders.app's own UI
doesn't expose hourly repeat either), so there's no faithful way to
represent it via `EKRecurrenceRule`.

Tested live against real Reminders.app data (add with daily/weekly/
monthly + custom interval + end date, edit to replace and to clear,
hourly correctly rejected, --repeat-interval/--repeat-until correctly
rejected without --repeat, conflicting --repeat + --clear-repeat
correctly rejected). Added Tests/RemindersTests/RecurrenceTests.swift
covering the frequency mapping, interval, end-date, and
representability logic at the unit level.

Note on test execution: this dev environment currently has only
Command Line Tools installed (no full Xcode), so `swift test` can't
link XCTest here (`xcrun --find xctest` fails) -- this affects the
pre-existing NaturalLanguageTests.swift identically, so it's an
environment gap, not something this change introduces. `swift build`
succeeds cleanly and all behavior was verified against the live
binary instead; the new test file is plain XCTest and should run
normally under CI or on a machine with full Xcode.
@rameshbaskaran

Copy link
Copy Markdown
Contributor Author

Update: installed full Xcode and re-ran swift test on this branch.

  • RecurrenceTests: 11/11 pass.
  • NaturalLanguageTests: 4 failures, but confirmed these are pre-existing on unmodified main too (reproduced identically by checking out main and running the same suite) — a timezone-string-rendering difference on this machine (Asia/Dubai locale, weekOfYear field ordering in the Calendar description), unrelated to this PR's changes.

So the earlier note about not being able to run swift test locally is resolved, and the new recurrence tests pass cleanly. Also did a fresh live smoke test against real Reminders.app with the built binary (reminders add ... --repeat weekly --format json) — recurrence field correctly set and readable back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature request: support recurrence rules (--repeat hourly/daily/weekly/monthly)

1 participant