Actually, I forgot how this works in most cases X-D.

And it happens through text properties, which backends add to their completion strings. Then the annotation and kind operations look them up.

As long as the completions have the same annotation (the text in green) and same kind (the icon on the left), they are deduplicated.

Looks like perhaps lsp-mode generates annotations that are more useful for your scenario than the ones that eglot does. If that is the case (and not, maybe, that you have configured lsp-mode/eglot to use different language servers), I suggest filing an issue. This shouldn’t take too much time to change.

What’s going on on the gif doesn’t look particularly smooth, so as long as the horizontal steps are limited to multiples of the character width, this should be easy to write in Emacs Lisp (5-10 lines).

But doing something practical with it will require extra work. I.e. the depicted process is probably a part of some specific buffer management/switching mechanism, and that would require some extra analysis to replicate and integrate.

Have you tried to use the same binding? python-ts-mode should have the same default set as python-mode due of how python-ts-mode-map is defined.

To see all available bindings, type C-h f python-ts-mode RET. You’re probably thinking of C-c < and C-c >.

The font lock rules in a lot of the TS modes are… not always thought through. Ramp up python-ts-mode’s font lock level to the maximum and most of everything is dyed the same colour.

And then on the other side, people come asking why even when TS is used, highlighting is not “up to par” with VS Code and etc. Then hear about treesit-font-lock-level, ramp it up to the max, and apparently live happily after.

Also try C-x p g for a similar UI.

Customize xref-search-program to make it use ripgrep under the covers.