I appreciate you weighing in here, but with all due respect this is homework you would have already done if you were serious about your FTS being on par with Lu

I appreciate you weighing in here, but with all due respect this is homework you would have already done if you were serious about your FTS being on par with Lucene, and that I shouldn't have to do for you. It's totally obvious just from comparing Elastic's documentation with Bleve's that Elastic has way more tokenizers and filters than Bleve. And it's also totally obvious from comparing Bleve's code to Dgraph's that Dgraph implements a subset of Bleve's. Whoever was responding to me on Slack sounded like they didn't even know what I was talking about. When I asked whether Dgraph planned to implement all of Bleve's tokenizers, the response I got was "Dgraph uses Bleve to generate the full-text tokens for the full-text index." When I pointed out that currently only some of them have been implemented and reiterated my question, the answer I got was "Dgraph's product decisions are independent of Bleve's features." Bleve would be a fine choice for FTS if you were planning on implementing the whole thing, writing additional analyzers to reach parity with Elastic, and preferably up-streaming them to Bleve. But if you're asking me to open a GitHub issue saying "will you please consider implementing the rest of Bleve?" the answer is no, thanks. I'll just revisit Dgraph some other time.