Quelpa moved back to github a while ago, as did quelpa-use-package. The minimum version requirement for the latter changed since the move. Update the links to reflect the changes.
Note that we also add a safety check in ORG-QL-VIEW--LINK-FOLLOW,
because the addition of a call to PROPERTIZE in
ORG-QL-VIEW--HEADER-LINE-FORMAT effectively removes what was
functioning as a safety check there (as CONCAT had been signaling an
error for the unsafe argument, whereas PROPERTIZE, which is called to
apply the new face, does not). We also change the expected error in
the tests accordingly.
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.
This allows searching within a narrowed buffer with org-ql-find.
Using "C-u" searches the widened buffer, while "C-u C-u" prompts to
select the buffers to search (which previously worked with just
"C-u").
Now all tests and lints pass on Emacs versions 27.1-29.4. But on the
current Emacs snapshot build used in CI, Buttercup is hanging
indefinitely, which may be the same problem that led Guix to disable
the tests in
<https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/emacs-xyz.scm?id=3add97c7761e6c58a1d7405f417a49dda5f0a742>.
But I've no way of knowing whether that's a problem in org-ql (seems
unlikely), Emacs snapshot, or Buttercup. It would be nice to solve
this before Emacs 30.1 is released, but I don't know how to peer
inside Buttercup to find out what it's hanging on.
Fixes#433.
Reported-by: Akira Komamura <akira.komamura@gmail.com>
Co-developed-by: Stefan Monnier <monnier@iro.umontreal.ca>
As the comment says, in CI the filenames are being abbreviated, which
I can't explain (it has not always been this way). So we compare them
in abbreviated form.
This omits the obsolete Org ELPA repository, which apparently was
causing a very old version of Org to be installed, which appeared to
be causing Buttercup to inexplicably hang (sometimes, on some systems,
in some circumstances...?).
I don't know if this is related to Guix commit
<https://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/emacs-xyz.scm?id=3add97c7761e6c58a1d7405f417a49dda5f0a742>,
which disables the tests due to Buttercup hanging, because Guix is not
running the tests through makem.sh.
The test data in v0.8.7 was accidentally changed to the English
abbreviation (the perils of working on systems with differing
locales), but the feature works as intended.
See <ffc3477013 (r143566834)>.
This does not solve the compilation warning, because that's caused by
the Pcase patterns at the end of the docstring, which the linter
falsely identifies as incorrect.
