Jens Schmidt <jschmidt4...@vodafonemail.de> writes: >> Backward compatibility will be easy - just leave the current code when >> old query version is detected. We should better focus on the new syntax >> in future and leave the current syntax as compatibility layer that will >> be eventually deprecated. > > Agreed except for the deprecation part. I think Org should be big enough > to have two parsers: One along the lines of the current one (infix, DWIM, > easy to type) and one along the lines of org-ql (sexp, better extensible, > more flexible, harder to type). Ideally, it should be even possible to > embed the infix-one into the sexp-one.
Maybe. The rough idea is to allow pluggable query syntax, so that people can implement they own, if they wish to. > It should also be possible to put the current infix parser onto a more > stable ground as well, based on a formal grammar, providing at least > parentheses for grouping and negation, and that without breaking backward > compatibility. > > Let's rephrase that way: If I were to redo the current parser as > mentioned in the previous paragraph, would these changes "eventually be > deprecated"? (Which doesn't necessarily mean that I promise to do so, > of course.) I am not sure if we need to hold to the current syntax. I am leaning towards something more similar to notmuch/"export" web search queries. In any case, deprecation is years away, and we will have plenty of time discussing the specifics. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>