Org 9.3 stopped replacing brackets in link descriptions with braces
and started escaping them instead.
Fixes#283. Thanks to Daniel Borchmann (@exot) for reporting.
See, e.g. <https://github.com/magnars/dash.el/pull/375>.
Ultimately I'd prefer to indent with one distinguished argument, but
the noise it causes downstream is likely not worth it. (And,
unfortunately, the indentation of the built-in thread-first and
thread-last forms has changed to be like this as well, which is even
worse, causing 10-11 characters of extra indentation in those forms'
bodies!)
Fixes#314, fixes#316. Thanks to Akira Komamura (@akirak) and Joon
Ro (@joonro) for reporting.
Instead of `[blank]` in this PEX, it used to be `(syntax-class
whitespace)`, which worked fine with peg v1.0. Then
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59345> was filed and
resulted in the release of peg v1.0.1, after which that no longer
worked. As best I can tell from reading the discussion, `[blank]` and
`(syntax-class whitespace)` should behave the same way, yet here they
do not: with peg v1.0.1, only `[blank]` works. Why, I do not know; I
only tried it because I could find no explanation for the broken
behavior, and luckily, it works. Maybe it's due to the use of
`(syntax-class whitespace)` later in the `pexs`; but since it finally
works again, let's take the victory as-is.
And use in org-ql-find. This seems to solve a problem I've been
noticing in helm-org-ql for a long time: that it can apparently
interrupt Org's initialization code, which can leave buffers
unprepared for Org, even stuck in fundamental-mode. This should also
be used in helm-org-ql...
This helps prevent unexpected errors from making it impossible to
search, and displaying the messages in the warnings buffer makes them
more noticeable and readable for the user.
Some argument combinations weren't normalized correctly and could
cause an infinite loop.
This commit doesn't update any corresponding tests, because they are
being rearranged in the WIP branch where this commit originates, and
teasing them out wouldn't be worth it.
e.g. if a predicate only accepts one argument, but the query gives
two, now the error will say, "PREDICATE called with 2 arguments, but
accepts only 1" (so maybe the predicate definition just needs
"&rest").
This is a breaking change of sorts in that searches using multiple
sorting methods will have to have the order of the sorters reversed to
get the same result. Unfortunate, but I think it's worth it in the
end, and this is pre-1.0, anyway.
Fixes#143.
