Hi. Thanks for working on git bug.
When creating a label containing a colon ":" character, the search seems to become unusable in the terminal user interface. After adding the label "st:wontfix" to a bug I tried to search with each of these:
Each threw the error "can't tokenize".
I would expect that either the colon character should be made illegal, or some other escape sequence be adopted to allow the search to cope with colons
This seems to be a problem on the web interface also.
Can confirm for latest release version (7.2). The current master version seems to allow the following search strings:
label:abc:abc fails with unkown qualifier "label:abc".
Also the WebUI seems to not show the open and closed bug count when using above filters. Instead only ??? is displayed as count.Edit: The WebUI will recieve unkown qualifier "label:abc" error for all above queries. Leading to ??? for bug count. Edit: Related https://github.com/MichaelMure/git-bug/pull/568
Very likely related to https://github.com/MichaelMure/git-bug/pull/568. It's a voluntary change in the query language where we allow to search with a triple foo:bar:baz. Before that, label:st:wontfix was interpreted (not by design) as label + st:wontfix. The correct way should be label:"st:wontfix" but maybe there is something wrong in the parser or in each UI?
The CLI and TermUI work by quoting the label string. The WebUI will display the matching bugs too, but the WebUI still recieves Error: unknown qualifier "label:abc" when using label:"abc:abc" as query string. Which is quite strange, as the graphql-playground won't give me an error...
PS: The error is not displayed anywhere. I had to add a console.log.
I think I've got the error. Let's see if I can fix it.
@MichaelMure I've got an idea. Why don't we use go's URLs package for query handling. The only syntax difference should be = instead of : for parameters. This could simplify the code significantly. Parsing would already (partially) be implemented and the WebUI can also use URLSearchParams API.
Well, this query language is a way for the user to interact with git-bug. The main goal has to be how well it does that job, not how easy it is to implement (as long as bugs are not an issue).
From that point of view, I'm happy to consider weakness of the language, but note that it has also a quite strong characteristic: it's very similar to the one github ans others have (so it's familiar to most users). Also, changing the query language now is technically a breaking change, it has to be well motivated.
I don't know what the issue is with the webUI, but it might be needed to re-implement the lexer/parser in javascript to easily modify a query: https://github.com/MichaelMure/git-bug/tree/master/query