No font-locking of the matched characters

[bbatsov]

I just tried company-flx and while it works, it's pretty hard to use it because there are no visual cues about what exactly was matched:

ido-flx would font-lock matched characters like this:

[PythonNut]

@dgutov I took a pass at implementing this a few months ago. Do you have any insights about adding arbitrary highlighting to the candidates in a front-end agnostic way?

Ideally, implementing it in the transformer would be easiest, but I don't mind doing it another way if I must.

[dgutov]

@PythonNut At the moment, arbitrar-ish highlighting is performed via the match backend command. Take a look at what company-capf does with it.

Since company-flx works via completion style, I wonder why the highlighting doesn't work as well here as it works for the partial-completion style.

You should try disabling company-mode, and using the completion style by pressing C-M-i. Is there highlighting in the *Completions* buffer?

[PythonNut]

@dgutov

At the moment, arbitrar-ish highlighting is performed via the match backend command.

It looks like the match command only reads text-properties? I don't see any highlighting being added.

I wonder why the highlighting doesn't work as well here as it works for the partial-completion style.

That highlighting only seems to work for showing a single contiguous range of highlighting, plus one highlight to show the next difference.

Adding faces in the transformer doesn't seem to work for me. :/

[dgutov]

It looks like the match command only reads text-properties? I don't see any highlighting being added.

Yes. The highlighting itself is added in company-fill-propertize, based on what match returns.

That highlighting only seems to work for showing a single contiguous range of highlighting, plus one highlight to show the next difference.

We could extend the manner of highlighting performed to use several ranges. However, why not start with "one contiguous range plus the next difference"?

Adding faces in the transformer doesn't seem to work for me. :/

Right. I didn't mean to imply that it will work.

[PythonNut]

Yes. The highlighting itself is added in company-fill-propertize, based on what match returns.

It looks like company is highlighting in the same manor as the completion style. One range to specify the common region.

We could extend the manner of highlighting performed to use several ranges. However, why not start with "one contiguous range plus the next difference"?

Fundamentally, the idea of "commonality" (as a single region) doesn't exist in fuzzy matching. Only the input, scattered across the candidates is guaranteed to be common to them all.

One contiguous range would present little gain when using fuzzy matching/sorting. The highlighting is there to show you how your input maps to the candidates, so you can understand why the optimal candidates are ranked the way they are. (Are the letters clustered at the beginning of word boundaries? Probably.) The goal of the highlighting is to help you grok the sorting heuristics so you can form optimal matches.

[dgutov]

Fundamentally, the idea of "commonality" (as a single region) doesn't exist in fuzzy matching.

Does it exist for the "partial completion" style, then? In practice, it does, even though it highlights different substrings in different candidates.

The goal of the highlighting is to help you grok the sorting heuristics so you can form optimal matches.

And the goal of showing the user where the "first difference" lies, is to indicate what the next character that the user types will be matched against.

[PythonNut]

Does it exist for the "partial completion" style, then? In practice, it does, even though it highlights different substrings in different candidates.

The problem with highlighting the region from the first match to the last is that it's slightly dishonest to the user. It's there to indicate that you should be interested in the part after the highlighting because the part highlighted is already matched.

For partial completion, the matching is stable. Adding characters to the query does not change the match positions of characters already in the query. Naive fuzzy matching also works this way. In these cases, the highlighting helps because you should be focusing on what's still unmatched.

However, intelligent fuzzy matching allows additions to the query to affect the positions of previous characters' matches. For example:

• coc-omp-2-com (matched against cocom)
• coc-omp-2-com (matched against cocom2)

Which means that highlighting the matched range from first match to last match doesn't have much meaning when the last match is in a highly volatile state.

And the goal of showing the user where the "first difference" lies, is to indicate what the next character that the user types will be matched against.

The "next difference" is, I think, used to highlight the next opportunity to disambiguate candidates. But that doesn't make sense with fuzzy matching because you can disambiguate using any distinct character after the last match, and sometimes even characters before the last match (if the last match can be shifted earlier).

[dgutov]

However, intelligent fuzzy matching allows additions to the query to affect the positions of previous characters' matches.

I see. In any case, though, first you should make your fashion of highlighting work in *Completions*, and then we can extend the match action to be able to return a list of ranges as well.

[seagle0128]

It's hard to use without color matching while typing.