Repeat Extensions: support a concrete base date in @repeat(interval, <date>) - #760
Merged
Merged
Conversation
…l, YYY-MM-DD) format The `generate repeats` action ignores the scheduled date or calendar note date, and repeats based on the YYYY-MM-DD concrete date Repeats with the relative (`+`) repeat interval modifier or with no concrete date fall through to the original behaviour Initial tests added around basic functionality.
Generalizes the concrete base date in @repeat(interval, <date>) to accept any NotePlan calendar-note date-spec (YYYY-Wnn, YYYY-MM, YYYY-Qn, YYYY) in addition to YYYY-MM-DD, mirroring the existing non-concrete behaviour. Advancing the concrete date in regenerated repeats now preserves its original format (e.g. 2026-W19 -> 2026-W20), including across 52/53-week year boundaries. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bumps plugin.version, adds a CHANGELOG entry, and adds standalone release notes for the concrete @repeat(...) base date feature (day/week/month/ quarter/year specs).
"Calendar-note date-spec" read as if the feature only worked in calendar notes. It works identically in project notes and calendar notes — the phrase was describing the date format, not a restriction on where the tag can be used.
jgclark
reviewed
Aug 1, 2026
|
|
||
| const EXTENDED_REPEAT_STR: string = `@repeat\\(${RE_DATE_INTERVAL}\\)` // find @repeat() | ||
| // A concrete @repeat(...) base date can be given in any NP calendar-note date-spec: day, week, month, quarter or year | ||
| const RE_CONCRETE_REPEAT_DATE: string = `(?:${RE_ISO_DATE}|${RE_NP_WEEK_SPEC}|${RE_NP_MONTH_SPEC}|${RE_NP_QUARTER_SPEC}|${RE_NP_YEAR_SPEC})` |
Collaborator
There was a problem hiding this comment.
Suggestion: I (now) try to use the convention that RE_* are actually of type RegExp, and other regex-related strings (like this), don't start with that. It makes for easier maintenance.
jgclark
reviewed
Aug 1, 2026
Collaborator
There was a problem hiding this comment.
The only doc files visible to plugin users are the README files (now via the NP website).
Thanks for writing this file (and updating the CHANGELOG) but it therefore needs to get incorporated into the relevant sections of the README.
jgclark
requested changes
Aug 1, 2026
jgclark
left a comment
jgclark
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for adding this, and ensuring there is good test coverage and documentation.
Just a couple of things to look at, please, and then I can release.
- Rename RE_CONCRETE_REPEAT_DATE (a plain string, not a RegExp) to CONCRETE_REPEAT_DATE_STR, matching the file's existing convention that RE_* is reserved for actual RegExp values. - Fold the concrete base date feature into the README, since only README files are surfaced to users; the standalone release-notes doc is kept as a more detailed reference.
3 tasks done
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
2 participants
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.
Summary
Adds an optional concrete base date to
@repeattags:@repeat(interval, <date>). When present, the next repeat is calculated from that fixed date rather than from the task's scheduled>dateor completion/cancellation date. After each completion or cancellation the embedded date is automatically advanced by the same interval, so the anchor rolls forward correctly for future cycles. Fully backward compatible — existing@repeat(interval)and@repeat(+interval)tags are unaffected.<date>accepts any of NotePlan's calendar-note date formats — day (YYYY-MM-DD), week (YYYY-Wnn), month (YYYY-MM), quarter (YYYY-Qn), year (YYYY) — and works the same whether the task lives in a project note or a calendar note.Precedence rules
@repeat(1m, 2026-05-12)— next repeat calculated from the concrete date, ignoring scheduled>dateand completion date.@repeat(+1m, 2026-05-12)—+prefix takes precedence: next repeat calculated from completion/cancellation date as before; concrete date is ignored for scheduling (a warning is logged). The anchor in the tag still advances by one interval, so it keeps a "rolling" anchor one interval behind the completion-date schedule.@repeat(1m)/@repeat(+1m)— unchanged.Full details, including year-end/52-vs-53-week edge cases and cancelled-task behaviour, are in
jgclark.RepeatExtensions/concrete-repeat-date-release-notes.md.Changes
helpers/NPExtendedRepeat.js— concrete-date detection/validation, advancing the anchor on completion (generateRepeatForPara) and cancellation (generateRepeatForCancelledPara).jgclark.RepeatExtensions/__tests__/repeatHelpers.test.js,helpers/__tests__/NPExtendedRepeat.generateRepeatForPara.test.js— new test coverage.jgclark.RepeatExtensions/CHANGELOG.md,plugin.json— v1.2.0.Test plan
npm run test:ci— 3800/3802 passing; the 2 failures are innp.Templating(locale-dependent date-format assertion, unrelated syntax-error test), pre-existing and untouched by this change.node scripts/rollup.js -b -ci— all 43 plugins build successfully.