Skip to content

Latest commit

 

History

History
76 lines (76 loc) · 4.47 KB

TODO.md

File metadata and controls

76 lines (76 loc) · 4.47 KB
  • list out todos
  • :Decscribe
  • clean up the view - too much metadata
  • separate tasks between each other
  • virtual buffer like in Octo/Oil
    • i.e. without corresponding file & with overriden load/save functions
    • implement save (:w)
    • save should modify modified
    • implement load (:e!)
    • custom name (vim.api.nvim_set_buf_name)
  • refactor set_entry to NOT use decscribe.py, but ONLY Lua + FFI
    • attach a todo's vcal form to every todo_json
    • actual refactor
  • fork libdecsync to silence/redirect Logging
  • remove decscribe.py completely | optimize libdecsync calls (too slow currently)
    • is it python?
    • is it ical parsing?
    • is it costly all-entries-recalculations?
    • everything is fast except (some part of decscribe.py) (maybe executing ALL entries too often?)
  • what's causing this long lag during first one/several :w's? (buffer changes during BufWriteCmd)
  • handle editing many todo items simultaneously
  • handle adding new items
  • handle removing
  • :DECSCRIBE COLLECTION-NAME
  • :Decscribe - provide autocompletion for existing collections
  • :Decscribe PATH-TO-DECSYNC-DIR COLLECTION-NAME
  • :Decscribe - simple path autocompletion for 1st arg
  • categories/tags
  • Tasks.org compliance?: sort categories alphabetically
  • priority as a number
  • priority as a letter
  • due dates
  • ical: if CATEGORIES are empty, remove the Ical entry altogether
  • ical: if any generic Ical field is empty, remove the Ical entry altogether
  • due datetimes
  • app.lua: write_buffer: refactor to impureim sandwich for easier testing
  • start dates (syntax: - [ ] 2022-06-12 .. 2022-06-29 09:00)
  • start datetimes (syntax: - [ ] 2022-06-12 09:00 .. 2022-06-29 09:00)
  • app.lua: read_buffer: refactor to impureim sandwich for easier testing
  • refactor Tasks class to simple functions on a simple struct -> collections.lua
  • subtasks
  • description
  • refactor to make writing tests less of a chore?
    • split app into data-format-agnostic core and two mappers (reader (parser) and shower) - ICal & Markdown
    • such that adding new fields to the whole app is like tweaking a declarative configuration passed into these mappers; the unit tests shall only test the generic part
  • calculate hash of each task to identify which tasks were just moved around the file, to avoid unnecessary creations + removals
  • if non-decsync-dir and/or non-collection given, create it
  • refactor ical struct to a map with a default sorting, instead of a list
  • consider nvim_buf_attach to continuously watch for buffer changes
  • handle complex hunks (mix of changes and removals/additions)
  • built-in / override to cycle through [HML] priorities
  • when existing items are moved, retain their UIDs instead of deleting and creating?
  • use extmarks for syntax highlighting?
  • use extmarks for diff-handling?
  • preconfigured ds-dirs:
    • :Decscribe NAME-OF-PRECONFIGURED-DECSYNC-DIR COLLECTION; and/or
    • :<range>Decscribe COLLECTION; and/or
    • :<range>Decscribe
  • fix repopulate_buffer disabling highlighting for some reason
  • don't reestablish libdecsync connection so often (i.e. with every repopulate_buffer) - keep it long living
  • memory leak - free Decsync* connections after the buffer is repopulated (a brand new connection is established)
  • with already established libdecsync connection, only refresh changed entries, not all
  • complex todo view, like Octo's PR view
  • multiple DS buffers can be open (different collections and/or DS dirs)
  • :Decscribe PATH-TO-DECSYNC-DIR COLLECTION-NAME - if collection not provided, create a new one with given name
  • :Decscribe - DS dir path autocompletion for preconfigured DS dirs
  • :Decscribe - DS dir path autocompletion for dynamically searched DS dirs
    • seeking .decsync-info files or using lds.check_decsync_info
    • up to n levels of directory recursion, not to overdo computation
    • async? to not block UI thread
  • at this point, todos collection view should be like just an MD file with nested lists
  • delete todo line(s) from one coll/ds-dir, and paste it/them into another => whole ICals are ported between colls/ds-dirs
    • i.e. all metadata like timestamps, uids etc. is preserved
  • edit and save todos (simple view of raw VDIR of given item)
  • ...
  • similar for calendar?