feat: omnifunc completion, recurring tasks, expanded date syntax (#27)
* feat(config): add recur_syntax and someday_date fields Problem: the plugin needs configuration for the recurrence token name and the sentinel date used by the `later`/`someday` named dates. Solution: add `recur_syntax` (default 'rec') and `someday_date` (default '9999-12-30') to pending.Config and the defaults table. * feat(parse): expand date vocabulary with named dates Problem: the date input only supports today, tomorrow, +Nd, and weekday names, lacking relative offsets like weeks/months, period boundaries, ordinals, month names, and backdating. Solution: add yesterday, eod, sow/eow, som/eom, soq/eoq, soy/eoy, +Nw, +Nm, -Nd, -Nw, ordinals (1st-31st), month names (jan-dec), and later/someday to resolve_date(). Add tests for all new tokens. * feat(recur): add recurrence parsing and next-date computation Problem: the plugin has no concept of recurring tasks, which is needed for habits and repeating deadlines. Solution: add recur.lua with parse(), validate(), next_due(), to_rrule(), and shorthand_list(). Supports named shorthands (daily, weekdays, weekly, etc.), interval notation (Nd, Nw, Nm, Ny), raw RRULE passthrough, and ! prefix for completion-based mode. Includes day-clamping for month/year advancement. * feat(store): add recur and recur_mode task fields Problem: the task schema has no fields for storing recurrence rules. Solution: add recur and recur_mode to the Task class, known_fields, task_to_table, table_to_task, and the add() signature. * feat(parse): add rec: inline token parsing Problem: the buffer parser does not recognize recurrence tokens, so users cannot set recurrence rules inline. Solution: add recur_key() helper and rec: token parsing in body() and command_add(), with ! prefix handling for completion-based mode and validation via recur.validate(). * feat(diff): propagate recurrence through buffer reconciliation Problem: the diff layer does not extract or apply recurrence fields, so rec: tokens written in the buffer are silently ignored on :w. Solution: add rec and rec_mode to ParsedEntry, extract them in parse_buffer(), and pass them through create and update paths in apply(). * feat(init): spawn next task on recurring task completion Problem: completing a recurring task does not create the next occurrence, and :Pending add does not pass recurrence fields. Solution: in toggle_complete(), detect recurrence and spawn a new pending task with the next due date. Wire rec/rec_mode through the add() command path. * feat(views): add recurrence to LineMeta Problem: LineMeta does not carry recurrence info, so the buffer layer cannot display recurrence indicators. Solution: add recur field to LineMeta and populate it in both category_view() and priority_view(). * feat(buffer): add PendingRecur highlight and recurrence virtual text Problem: recurring tasks have no visual indicator in the buffer, and the extmark logic uses a rigid if/elseif chain that does not compose well with additional virtual text fields. Solution: add PendingRecur highlight group linking to DiagnosticInfo. Refactor apply_extmarks() to build virtual text parts dynamically, appending category, recurrence indicator, and due date as separate composable segments. Set omnifunc on the pending buffer. * feat(complete): add omnifunc for cat:, due:, and rec: tokens Problem: the pending buffer has no completion source, requiring users to type metadata tokens from memory. Solution: add complete.lua with an omnifunc that completes cat: tokens from existing categories, due: tokens from the named date vocabulary, and rec: tokens from recurrence shorthands. * docs: document recurrence, expanded dates, omnifunc, new config Problem: the vimdoc does not cover recurrence, expanded date syntax, omnifunc completion, or the new config fields. Solution: add DATE INPUT and RECURRENCE sections, update INLINE METADATA, COMMANDS, CONFIGURATION, HIGHLIGHT GROUPS, HEALTH CHECK, and DATA FORMAT. Expand the help popup with recurrence patterns and new date tokens. Add recurrence validation to healthcheck. * ci: fix * fix(recur): resolve LuaLS type errors Problem: LuaLS reported undefined-field for `_raw` on RecurSpec and param-type-mismatch for `last_day.day` in `advance_date` because `osdate.day` infers as `string|integer`. Solution: Add `_raw` to the RecurSpec class annotation and cast `last_day.day` to integer in both `math.min` call sites. * refactor(init): remove help popup, use config-driven keymaps Problem: Buffer-local keymaps were hardcoded with no way for users to customize them. The g? help popup duplicated information already in the vimdoc. Solution: Remove show_help() and the g? mapping. Refactor _setup_buf_mappings to read from cfg.keymaps, letting users override or disable any buffer-local binding via vim.g.pending. * feat(config): add keymaps table for buffer-local bindings Problem: Users had no way to customize or disable buffer-local key bindings in the pending buffer. Solution: Add a pending.Keymaps class and keymaps field to pending.Config with defaults for all eight buffer actions. Setting any key to false disables that binding. * feat(plugin): add Plug mappings for all buffer actions Problem: Only five of nine buffer actions had <Plug> mappings, so users could not bind close, undo, open-line, or open-line-above globally. Solution: Add <Plug>(pending-close), <Plug>(pending-undo), <Plug>(pending-open-line), and <Plug>(pending-open-line-above). * docs: update mappings and config for keymaps and new Plug entries Problem: Vimdoc still listed g? help popup, lacked documentation for the four new <Plug> mappings, and had no keymaps config section. Solution: Remove g? from mappings table, document all nine <Plug> mappings, add keymaps table to the config example and field reference, and note that buffer-local keys are configurable.
This commit is contained in:
parent
6911c091f6
commit
7d93c4bb45
18 changed files with 1536 additions and 134 deletions
|
|
@ -10,6 +10,8 @@ local store = require('pending.store')
|
|||
---@field status? string
|
||||
---@field category? string
|
||||
---@field due? string
|
||||
---@field rec? string
|
||||
---@field rec_mode? string
|
||||
---@field lnum integer
|
||||
|
||||
---@class pending.diff
|
||||
|
|
@ -48,6 +50,8 @@ function M.parse_buffer(lines)
|
|||
status = status,
|
||||
category = metadata.cat or current_category or config.get().default_category,
|
||||
due = metadata.due,
|
||||
rec = metadata.rec,
|
||||
rec_mode = metadata.rec_mode,
|
||||
lnum = i,
|
||||
})
|
||||
end
|
||||
|
|
@ -90,6 +94,8 @@ function M.apply(lines)
|
|||
category = entry.category,
|
||||
priority = entry.priority,
|
||||
due = entry.due,
|
||||
recur = entry.rec,
|
||||
recur_mode = entry.rec_mode,
|
||||
order = order_counter,
|
||||
})
|
||||
else
|
||||
|
|
@ -112,6 +118,14 @@ function M.apply(lines)
|
|||
task.due = entry.due
|
||||
changed = true
|
||||
end
|
||||
if task.recur ~= entry.rec then
|
||||
task.recur = entry.rec
|
||||
changed = true
|
||||
end
|
||||
if task.recur_mode ~= entry.rec_mode then
|
||||
task.recur_mode = entry.rec_mode
|
||||
changed = true
|
||||
end
|
||||
if entry.status and task.status ~= entry.status then
|
||||
task.status = entry.status
|
||||
if entry.status == 'done' then
|
||||
|
|
@ -135,6 +149,8 @@ function M.apply(lines)
|
|||
category = entry.category,
|
||||
priority = entry.priority,
|
||||
due = entry.due,
|
||||
recur = entry.rec,
|
||||
recur_mode = entry.rec_mode,
|
||||
order = order_counter,
|
||||
})
|
||||
end
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue