It is impossible to search for a : character in literal search mode because we treat it as a special character to denote a search filter. Escaping \: does not work, and you can't wrap it in quotes.
Slack thread: https://sourcegraph.slack.com/archives/C07KZF47K/p1572557671374200
The thread has one suggested solution which is to relax the filter parsing we do. If a user puts a colon, and the filter is not valid, we should treat the colon surrounding string as literal, not as a filter.
The pushback is that users would then not know if they put an invalid filter if they got no results, but RFC 14 will introduce keyword highlighting that will decorate filters that are detected in the query.
The other problem would be that you might want to search for something that is also a valid filter, e.g. file:.*foobar to search for a property declaration file followed by something containing foobar. There might be ways to then workaround that again, but it would further mystify the search syntax instead of improving confusion, and you get into a rabbit hole of workarounds.
It is not possible to search for patterns that clash with our parser syntax without a quote/escape mechanism. We've decided not to add escaping to literal search for the foreseeable future. But: it is now possible to work around this issue for all searches using the content: field, which overrides the search pattern. So, the following are all valid and work as expected:
content:"repo:foo"
content:"file:.*foobar"
etc.
Most helpful comment
It is not possible to search for patterns that clash with our parser syntax without a quote/escape mechanism. We've decided not to add escaping to literal search for the foreseeable future. But: it is now possible to work around this issue for all searches using the
content:field, which overrides the search pattern. So, the following are all valid and work as expected:content:"repo:foo"content:"file:.*foobar"etc.