hvis

Would you consider changing this, since this way of deduplication in the frontend is quite inefficient?

I simply consider it part of the requirements (see the other message). And there has been some effort made to ensure that the annotation/kind functions are only called when equal strings are encountered.

Indeed, when the list is long deduplication does show up on the graph, but the impact also depends on the shape of the data, and there probably are some untapped code optimizations still.

Deduplicating in the backend is not difficult, all that is needed is adding a suffix like (1), (2), (3), ...

I'm not sure this is very easy (e.g. for LSP clients), and in general it would require a scan across all completions of comparable complexity. Also, showing method overloads with suffixes like 1/2/3 would look rather odd, I think.

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.

Something like that would be generally easy to see very soon (completion popup without both icons and annotations). This approach has worked for years for both Emacs's default UI and company-mode, so it's hard to call it fragile.

I suppose it might have been a cause for investigation for some backend authors at some point, but backends would generally avoid internal copying anyway, for performance reasons if nothing else.

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.

Like the article mentions, gestures could be even more handy when used with a touch interface.

Such as the new Android port of Emacs, for example.

These two bindings work for me. Does C-h f python-ts-mode RET show them in the list?

Ah, actually, Emacs supports pixelwise window resizing as well.

So it basically comes down to choosing (and implementing) the window management logic which would do something like this for the sake of anything practical.

And making sure that no third-party packages slow down redisplay enough that this movement becomes too jerky.

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 >.

You're welcome.

So your complaint is about the non-default behavior? The level 3 was chosen as default explicitly to avoid the abundance of color where it's not really needed.

I said monochromacity: that at the highest level, many disparate node types are font locked with the same face. Try it in Python. Everything is the same shade of whatever your variable name face is.

I don't see that "everything is the same shade", even with level 4. There are problems - like the variable matches in particular (which is not useful IMO, but should at least use a different face). The rest use different faces, but since most of those faces are new, it's up to the theme authors to differentiate them.

Here's a patch fixing the one problem I found (try it), and below is a screenshot with this patch applied along with the new faces customized to be distinct.

diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index d3cb5a77e22..9f9344e0eb4 100644
***
a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -1235,7 +1235,7 @@ python--treesit-fontify-variable
   (when (python--treesit-variable-p node)
     (treesit-fontify-with-override
      (treesit-node-start node) (treesit-node-end node)
-     'font-lock-variable-name-face override start end)))
+     'font-lock-variable-use-face override start end)))
 
 
 ;;; Indentation

https://imgur.com/a/iifAmcd

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.