You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
label:st:wontfix
label:"st:wontfix"
label:'st:wontfix'
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
Can confirm for latest release version (7.2).
The current master version seems to allow the following search strings:
label:"abc:abc"
label:'abc:abc'
Though 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 #568
Very likely related to #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.
@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.
Activity
artumi-richard commentedon Apr 26, 2021
This seems to be a problem on the web interface also.
GlancingMind commentedon Apr 29, 2021
Can confirm for latest release version (7.2).
The current master version seems to allow the following search strings:
Though
label:abc:abcfails 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 #568
MichaelMure commentedon Apr 29, 2021
Very likely related to #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:wontfixwas interpreted (not by design) aslabel+st:wontfix. The correct way should belabel:"st:wontfix"but maybe there is something wrong in the parser or in each UI?GlancingMind commentedon Apr 29, 2021
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.
GlancingMind commentedon Apr 29, 2021
I think I've got the error. Let's see if I can fix it.
GlancingMind commentedon Apr 29, 2021
@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.
MichaelMure commentedon Apr 29, 2021
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