e.g. in a source block containing Bash shell code like:
[[ -z $data ]]
The matched groups could be null, since it's not actually an Org link,
so calling STRING-MATCH-P on them would signal an error.
Reported-by: John Wiegley <jwiegley@gmail.com>
Now all tests and lints pass on Emacs versions 27.1-29.4, and the
current 30.0.50-ish snapshot build.
Note: This change was originally applied on master, but it seems
reasonable to apply it to this stable bugfix release now.
Fixes#433.
Reported-by: Akira Komamura <akira.komamura@gmail.com>
Co-developed-by: Stefan Monnier <monnier@iro.umontreal.ca>
This allows a query like this:
(level <= (string-to-number (property PROPERTY)))
to proceed without signaling an error from ORG-QL--QUERY-PREAMBLE.
See #460.
Reported-by: Stewmath <https://github.com/Stewmath>
Supporting this form isn't really required, since it violates the
CL-style argument parsing of CL-DEFUN, but it's convenient, and
probably saves some hair-pulling for users who are less familiar with
Elisp.
Fixes#460.
Reported-by: Stewmath <https://github.com/Stewmath>
* org-ql-completing-read.el (org-ql-completing-read-snippet): Call
snippet function with argument
(org-ql-completing-read): Call snippet function passed in rather than
hard-coded function.
(org-ql-completing-read--snippet-simple): Accept optional, ignored argument.
(org-ql-completing-read--snippet-regexp): Make argument optional;
rename for clarity.
Fixes#419.
Reported-by: tpeacock19 <https://github.com/tpeacock19>
Modes like org-indent-mode and org-modern can add text properties to
to-do keywords in Org buffers, and those properties can "bleed over"
when org-element copies those regions into strings. When those
strings are then displayed in an org-ql-view buffer, they can affect
how the keywords appear, e.g. having extra spaces prefixing them,
which breaks alignment. We apply faces to the keywords ourselves, so
we don't need any properties from the source buffer.
Fixes#455.
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.
