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.
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.
