I'm not sure why calling the REC labeled function didn't correctly
normalize these sub-queries; it seemed to only normalize for one
round, leaving some queries incorrectly normalized. But this fixes
it.
Fixes#365.
Reported-by: Gabriele Mongiano <https://github.com/kofm>
Use the base buffer if it has one, because if we run the search from
an indirect buffer, it's likely already narrowed to a different entry,
and making an indirect buffer from that one would end up with a
restriction that would likely hide the selected entry.
These commands were removed in 5768c685ad,
but they were still mentioned in the release that was going to
incorporate those two functions, v0.7.
This commit removes the mention of those two functions from the v0.7
subheading in the changelog. Note that `org-ql-find-path` was
re-introduced in v0.8, so it remains under that subheading as a separate
addition.
I don't fully understand why this is the correct fix, because I don't
know where the raw heading text is being linkified (it seems like the
:raw-value property should be the unlinkified text), but this seems to
work correctly now. If it turns out to break something else, we'll
find out and fix it.
Fixes#282.
Reported-by: Jacob Boxerman <https://github.com/jakebox>
This fixes the case in which a user calls org-ql-find from a narrowed
buffer and chooses a result outside the restriction. This is already
done in, e.g. org-ql-open-link; it's just an oversight here.
Hopefully this does not cause a noticeable performance impact. Maybe
the new org-element caching features in Org will help with that.
Fixes#363.
Reported-by: Gabriele Mongiano <https://github.com/kofm>
It didn't seem that calling custom-save-all was necessary in the past,
but it appears that it is now.
Closes#378.
Reported-by: Pentaquark1 <https://github.com/Pentaquark1>
COMPLETING-READ, when used with its REQUIRE-MATCH argument, would not
allow a result to be selected when ORG-QL-FIND was called with its
QUERY-PREFIX argument.
This change moves where the query is modified to include the prefix,
putting it into the RUN-QUERY function instead of the COLLECTION
function. It seems to solve the problem, and the function seems to
still work when used without QUERY-PREFIX. However, due to the
complexity of all this (we really need a SELECTING-READ API), it
wouldn't surprise me if something is later found to have been broken
by it...
Fixes#351.
Reported-by: Daniel Fleischer <https://github.com/danielfleischer>
