Its not right but not unexpected. insource:"" segments words in the same way that we segment regular text. I can't think of a workaround for you at this point either - the insource:// is going to be slow unless you have another filter like insource:"" but insource:"" is too much for you.

Thinking out loud for a solution: I wonder if its safe to trick the language analyzer by pretending that ".", ":", "/" are " ". That'll cause splits where we want them I think. I'm not sure if that is right for all text in all languages but, maybe?

Oh, so URLs are one "segment", and this doesn't find "substrings"? That makes sense.

Splitting on these characters sounds reasonable to me. There are some cases like "AC/DC", but that shouldn't cause any problems, right?

(In reply to Bartosz Dziewoński from comment #2)

Oh, so URLs are one "segment", and this doesn't find "substrings"? That
makes sense.

Splitting on these characters sounds reasonable to me. There are some cases
like "AC/DC", but that shouldn't cause any problems, right?

You've got it. The way search works is that all the words are segmented (tokenized) and then normalized and then indexed for quick lookup. The trick is that each language is subtly different and I only speak English so I can only validate that choices make sense there. And its hard to propose changes that cross many languages.

Anyway, I'll see if I can make a tool to easily look at how words are segmented in your language. And I'll see if I can make it easy to experiment a bit with stuff.

Works now!

This was probably fixed by my change to the analyzer to consider . like space. It wasn't just fixed magically - just as the solution to another bug.