sourcegraph / sourcegraph-public-snapshot

Code AI platform with Code Search & Cody
https://sourcegraph.com
Other
10.1k stars 1.27k forks source link

RFE: Shorter syntax for searching multiple languages #41224

Open mike-r-mclaughlin opened 2 years ago

mike-r-mclaughlin commented 2 years ago

Requested by: https://github.com/sourcegraph/accounts/issues/6716 via Slack

Feature request description

It would be nice to make searching across multiple specific languages. The way the query syntax works now requires you to use boolean OR logic like this:(lang:language1 OR lang:language2)

From the user:

That is a lot to type if you need search multiple languages frequently. If the same functionality were available in a shorter syntax like lang:language1,language2 or lang:language1|language2 would be a helpful enhancement.

Example use case

I often need to search across both JavaScript and TypeScript files, so I use something like this: \bkeyword\b (lang:typescript OR lang:javascript)

Describe alternatives you've considered.

Create a personal search context, that adds (lang:typescript OR lang:javascript) and select that search context. This is a bit clunky. But it might help.

Use search snippets.

"search.scopes": [
    {
      "name": "JavaScript & TypeScript",
      "value": "(lang:typescript OR lang:javascript)"
    }
  ]

/cc @sourcegraph/search-platform/search-core

keegancsmith commented 2 years ago

cc @rvantonder

rvantonder commented 2 years ago

I'm generally in favor of ergonomic adjustments to syntax to support this kind of thing, and maybe a | operator on lang is OK. In general though I hesitate to make an adjustment like this in the core language, and it might be better to support via a surface syntax (an implementation/design layer that doesn't exist right now).

camdencheek commented 6 months ago

This would still be nice, also for multiselection of other things. I think we could support this language-wise with a predicate like lang:in(Typescript, Javascript).

This could also be helpful for our query evaluation since right now we need to DNF the query before evaluating an OR. If we have a syntax construct that is essentially an OR but for a single filter type, that would be significantly easier to optimize.