Add --repeat recurrence support for add/edit (closes #104) - #109
Open
rameshbaskaran wants to merge 1 commit into
Open
rameshbaskaran wants to merge 1 commit into
rameshbaskaran wants to merge 1 commit into
Conversation
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.
Contributor
Author
|
Update: installed full Xcode and re-ran
So the earlier note about not being able to run |
udondan
pushed a commit
to udondan/reminders-cli
that referenced
this pull request
Sep 13, 2026
Implements EKRecurrenceRule-backed recurrence: - `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. `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`. Ported from keith/reminders-cli#109, authored by Ramesh Baskaran.
udondan
added a commit
to udondan/reminders-cli
that referenced
this pull request
Sep 13, 2026
EventKit doesn't advance dueDateComponents on a repeating EKReminder as occurrences pass, so a recurring reminder's due date can end up arbitrarily overdue rather than reflecting the next actionable occurrence (observed directly against Reminders.app; documented in the README since Apple doesn't cover this behavior). hasRecurrence is now always encoded as a boolean so scripts don't have to check for a missing or null field. nextDueDate steps the recurrence rule's frequency/interval forward from its due date, honoring --repeat-until/occurrence-count ends, and is only populated for the plain daily/weekly/monthly/yearly rules this CLI itself creates and edits. Extends the recurrence support ported from keith/reminders-cli#109 and #110. Co-authored-by: Ramesh Baskaran <ramesh.baskaran@gmail.com> Co-authored-by: Aleksei Morozov <246998741+morozovpersonal@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #104.
What
Adds
EKRecurrenceRule-backed recurrence support:reminders add <list> <reminder> --repeat daily|weekly|monthly|yearly--repeat-interval Nto repeat every N units instead of every 1 (default 1), e.g.--repeat-interval 2 --repeat weeklyfor 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-repeatremoves it entirely.--format jsonoutput now includesrecurrence,recurrenceInterval, andrecurrenceEndfields when present.Why
hourlyis rejected rather than supportedEKRecurrenceFrequencyhas no hourly case -- Reminders.app's own UI doesn't expose hourly repeat either. Rather than silently degrade--repeat hourlyto a daily rule (which would be a functional lie about what was actually configured), it's rejected atvalidate()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,
hourlycorrectly rejected with the explanatory error,--repeat-interval/--repeat-untilcorrectly rejected when used without--repeat, and the--repeat+--clear-repeatconflict correctly rejected.Added
Tests/RemindersTests/RecurrenceTests.swiftcovering the frequency mapping, interval, end-date, and representability logic at the unit level.Note on
swift testlocally: my dev machine currently only has Command Line Tools installed (no full Xcode), soswift testcan't link XCTest here (xcrun --find xctestfails) -- this affects the pre-existingNaturalLanguageTests.swiftidentically, confirming it's a local environment gap and not something this PR introduces.swift buildsucceeds 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 confirmswift testpasses 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-intervaldefaults to 1, omitting--repeat/--repeat-untilleaves existing behavior untouched). No changes to existing flag behavior or output format for reminders without a recurrence rule.