We may need these in the future, so rather than have to dig these back
out of org-agenda.el, I'll just comment them out for now. This
silences the byte-compiler.
org-agenda-new-marker sometimes raises "selecting deleted buffer"
errors, and other times returns markers that don't point into a
buffer (I don't even know how that's possible). copy-marker always
works, so we'll use it, even though it might leave markers hanging
around which theoretically could affect performance over time (but
isn't Emacs still supposed to GC them? I'm not sure).
Also, rename it to org-ql--add-markers, since we're not adding
"agenda" markers anymore.
Using org-agenda-mode isn't exactly *correct*, but since we use some
compatible text properties, it does give us some functionality for
free, even if it isn't 100% compatible.
Note that this should be considered experimental. It's not
unimaginable that using some agenda buffer commands in the agenda-ng
buffer could have unexpected consequences, including data corruption.
However, basic ones like jumping to entries and org-agenda-priority
seem to work.
By using s-join instead of org-agenda-finalize-entries, which does its
own sorting. We don't need anything it does, at least not now, and if
we ever do, we'll probably want to reimplement it, anyway.
HOWEVER, this breaks org-super-agenda, which uses advice to that
function to group items. So we need to either figure out another
approach (which I have been unable to do so far, trying cl-letf,
cl-flet, and advice-add with unwind-protect), or make this depend on
org-super-agenda.
Not sure when I broke this, but this fixes it. Still probably need to
refactor a bit, as there's some cross-dependency between org-agenda-ng
and org-ql.
When formatting an element outside the element's buffer (e.g. when
mapping --format-element across the results of org-ql), the current buffer
is not the element's source buffer, so functions like org-get-tags-at
will not return the correct results, because they don't use the
marker's buffer. So now we set the current buffer to the marker's
buffer.
As this package matures, this might become unnecessary in the future,
but it's probably best to keep it for correctness.
