Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend and/or queries to return multiple result types #10623

Closed
rvantonder opened this issue May 12, 2020 · 4 comments
Closed

Extend and/or queries to return multiple result types #10623

rvantonder opened this issue May 12, 2020 · 4 comments
Assignees

Comments

@rvantonder
Copy link
Contributor

rvantonder commented May 12, 2020

Example, this query newRouter or file:router.go should work and return both results types.

https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/sourcegraph/sourcegraph%24+newRouter+or+file:router.go&patternType=regexp

and

similarly file:main.java AND reserved should work as an alias for file:main reserved

This is separate from expanding and/or queries to arbitrary scope (nested queries). It concerns the type of the expression result.

(This is a significant chunk of work that I've had in mind, but hadn't create an issue yet. Will likely happen in one or two iterations in future at the current pace of things.)

@rvantonder
Copy link
Contributor Author

rvantonder commented May 22, 2020

Self note: use case by @rrhyne

but not lang:php OR lang:javascript. How would I accomplish the latter filter?

This one is interesting because we don't support regex as a lang field, so would actually have to expand something like lang:php or lang:javascript foo => lang:php foo or lang:javascript foo.

@rrhyne
Copy link
Contributor

rrhyne commented May 22, 2020

This may become more important depending on how RFC 159 resolves.

The use case is: allow a user to limit the scope of queries run on sourcegraph.com/search to languages they know and therefore more interested in.

There may be other ways to accomplish this as well, so if you can think of anything, please comment on that RFC!

@rvantonder
Copy link
Contributor Author

The note above is more of an implementation concern. We will support it one way or another with something as simple as lang:php or lang:javascript, like in the original query. It may just be a function of internally rewriting the query in the backend. I added my thoughts re syntax (which is slightly orthogonal to the note above) in RFC 159 :-)

@rvantonder
Copy link
Contributor Author

Closing in favor of the search expressions issue 13126, which reflects the most up-to-date functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants