You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When editing a long list of events, it feels clunky to go through per-event prompting to modify and save events one at a time. What if instead it supported an interactive TUI (text-based UI) where you could browse the entire list of events, stage edits to them, and then commit them to save all changes at once.
In other words, this would be like editing the set of events visually in vi vs. ed.
That kind of TUI interface would offer a few advantages over the current line-based interface:
More forgiving experience if you e.g. started editing a few, changed your mind, and wanted to abort and start the whole edit over with different parameters
More convenient if you want to only edit a couple individual fields without going through prompts for all the others
Could offer more intuitive controls for batch operations like "add reminder xyz on just these 7 events in the list"
Could allow for better ad hoc searching/filtering within the TUI, for a richer browsing+editing experience across your events
The text was updated successfully, but these errors were encountered:
Neat, I didn't realize that's what the agendaupdate command did!
Still some advantages of doing edits completely inline in something like a TUI w/o separate intermediate files, like having a more convenient flow for exploring and updating very large sets of event data interactively w/o having to craft cli args upfront to filter the data down manually.
When editing a long list of events, it feels clunky to go through per-event prompting to modify and save events one at a time. What if instead it supported an interactive TUI (text-based UI) where you could browse the entire list of events, stage edits to them, and then commit them to save all changes at once.
In other words, this would be like editing the set of events visually in vi vs. ed.
That kind of TUI interface would offer a few advantages over the current line-based interface:
The text was updated successfully, but these errors were encountered: