Skip to content

Label naming #655

Closed
Closed

Description

@artumi-richard

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:

  • 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

Activity

  1. artumi-richard commented on Apr 26, 2021

    @artumi-richard
    Author

    This seems to be a problem on the web interface also.

  2. GlancingMind commented on Apr 29, 2021

    @GlancingMind
    Contributor

    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

  3. MichaelMure commented on Apr 29, 2021

    @MichaelMure
    Contributor

    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?

  4. GlancingMind commented on Apr 29, 2021

    @GlancingMind
    Contributor

    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.

  5. GlancingMind commented on Apr 29, 2021

    @GlancingMind
    Contributor

    I think I've got the error. Let's see if I can fix it.

  6. GlancingMind commented on Apr 29, 2021

    @GlancingMind
    Contributor

    @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.

  7. MichaelMure commented on Apr 29, 2021

    @MichaelMure
    Contributor

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions