- [ ] Unify some subroutines for capture/refile/extract/insert/find
- [ ] In 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 in future
(cadar (org-collect-keywords "TITLE"))
->(org-get-title)
;;;###autoload (autoload 'org-node-series-dispatch "org-node" nil t)
- In Emacs 30, replace with just
;;;###autoload
- In Emacs 30, replace with just
- any code gated on
emacs-major-version
- any usages of
compat-call
org-element-with-disabled-cache
, it may be safe to remove in 30cl-sort
- what the compiler tells you is obsolete
- [ ] Manage org-super-links drawers
- [ ] With the above fixed, it’ll be close at hand to make a RELATED-drawer, another concept from org-super-links
- [ ] A workflow to allow untitled nodes (e.g. numeric-titled)
Already
org-node-grep
can be considered an equivalent toorg-node-find
(except it does not create new nodes) so we “just” need an equivalent toorg-node-insert-link
. Basically, capture, refile, and insert-link would probably all reuse a subroutine for identifying a node by a grep result. - [ ] For even more perf (unnecessary): keep subprocesses alive, or track all data that came from each file so as to not re-scan if mtime has not changed, or both
- [ ] org-node-seq-dispatch: Free up keys “j” “n” “p”, “c”
- [ ] More org-node-seq-defs wrappers:
- [ ] Define a seq from the links the body text of a single “master node” if that node has a tag such as :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.