Skip to content

Latest commit

 

History

History
53 lines (31 loc) · 2.88 KB

TODO.org

File metadata and controls

53 lines (31 loc) · 2.88 KB

To reduce LoC

  • [ ] Unify some subroutines for capture/refile/extract/insert/find
  • [ ] Mid-2025: drop Emacs 28

    (Seems that Debian stable will be stuck on Emacs 28 until mid-2025, then likely leap to Emacs 30.)

    List of 28-isms and 29-isms to drop

    • (cadar (org-collect-keywords "TITLE")) -> (org-get-title)
    • ;;;###autoload (autoload 'org-node-seq-dispatch "org-node-seq" nil t)
      • In Emacs 30, replace with just ;;;###autoload
    • any code gated on emacs-major-version
    • any usages of compat-call
    • org-element-with-disabled-cache, it may be safe to remove in 30
    • cl-sort
    • what the compiler tells you is obsolete

Other

  • [ ] Write a glossary, to clarify e.g. what is a “ref” vs “reflink”
  • [ ] Absorb org-roam’s backlink buffer #74
  • [ ] Manage BACKLINKS drawers (like org-super-links)
  • [ ] Manage RELATED drawers (just because it would be easy after the above is done)
  • [ ] org-node-seq-dispatch: Free up keys “j”, “n”, “p”, “c”
  • [ ] A workflow to allow untitled nodes (actually pseudo-untitled, the title would be an auto-assigned number)

    Already org-node-grep can be considered an equivalent to org-node-find (except it does not create new nodes). We “just” need an equivalent to org-node-insert-link. Basically, capture, refile, and insert-link would probably all reuse a subroutine for identifying a node by a grep result.

  • [ ] More org-node-seq-defs wrappers:
    • [ ] Point at single “master node” that defines a seq: links in the body text are the seq.
    • [ ] Define a seq from simply the files in a subdirectory with a given name
  • [ ] Accept more ref variants as the same ref

    If a roam-ref exists like //www.website.com, allow counting a link //www.website.com?key=val&key2=val2#hash as a reflink to the same, unless the latter has a roam-ref of its own.

    Would prolly be a fairly expensive operation. After building tables ref<>id and dest<>links, run thru every dest and check if an existing ref is a prefix of it, then simply nconc the value with the value for the corresponding dest. But having to check for other dests that may also be a prefix is where it would get expensive… O(n^2) I guess.

    Hm… Sort all dests alphabetically. All near-matches will be very close to each other, and indeed an alphabetic sort even results in a sort-by-length within each possible “group”. So just run down progressively shorter prefixes until the length goes up again, then we know we’re in another group. Rough idea, but O(n^2) looks beatable.

  • [ ] … Inspired by variable org-id-link-consider-parent-id, maybe scan all Org entries whether they have an ID or no, for the option to show some ID-less entries according to an user-defined rule.

    But better instead expend our efforts on https://edstrom.dev/hnzgj/proposal-make-org-mode-fast-for-real