Not sure I understood your point.

There are GUI versions for Windows/Linux/Mac/etc: https://www.vim.org/download.php

I use GVim (without the menu/tool bars).

It's still a TUI. I would like Vim to be able to e.g. draw a normal line instead of changing the background of a column of characters, when cc is set. Also not needing to patch fonts to get things like powerline. That and other things of this nature.

Again, I don't understand your point. GVim is GUI, not TUI.

A GUI can draw vector graphics, like lines, arcs, arrows etc. GVim still behaves like a terminal, which just has a grid of characters to work with. Any such vector graphics is done awkwardly with fonts, which doesn't give the best result, and patching fonts is not the best UX.

Thanks for further clarification. I haven't needed such capability in a text editor, but probably I should look into what that provides.

And I don't see how such features are necessary to rule GVim as GUI. I have a fairly basic classification: TUI runs in a terminal, GUI have their own windows.

GVim is a GUI in the same way that a terminal app is technically a GUI. It is surrounded by GUI chrome and has menus and such, but you are working with unstyled plaintext as you would in any other terminal window.

Put this another way, you can tell the difference between something like vim and Emacs versus Kate and Microsoft Word. It is not necessary to get into the minutia of what makes all these text editors different to understand that they are fundamentally different kinds of applications. The former two are clearly terminal apps with GUI chrome around them, the latter two are clearly GUI apps.

Think what you're asking for is a vim interface built around arbitrary mouse usage and discovery, the latter being of utmost emphasis I presume. And yeah, it's a valid complaint that vim GUI implementers seem incapable of getting to that level and just put chrome around what is essentially a TUI instance.

Lack of mouse-led discovery likely also contributes to vim veterans being surprised that vim has this or that feature. TUI-orientation is quite tenuous when it comes to discovery of behavior. The whichkey family of plugins[0][1] is an interesting experiment in combatting this, but does nothing for the large case of commands that aren't mapped to a key by default, like the example of the 'earlier' command mentioned higher in this thread.

[0]https://github.com/folke/which-key.nvim

[1]https://github.com/liuchengxu/vim-which-key