4 ms·

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

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.

asicsp 4y ago
Again, I don't understand your point. GVim is GUI, not TUI.
- yakubin 4y ago
  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.
  - asicsp 4y ago
    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.
    - Izkata 4y ago
      You said above you use it without the menu/toolbars, which is the GUI interface. What you've described is identical to, say, "xterm -e vim", so, TUI.
    - Karunamon 4y ago
      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.
      - imbnwa 4y ago
        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 https://github.com/folke/which-key.nvim [1]https://github.com/liuchengxu/vim-which-key https://github.com/liuchengxu/vim-which-key

asicsp 4y ago

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

yakubin 4y ago
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.
- asicsp 4y ago
  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.
  - Izkata 4y ago
    You said above you use it without the menu/toolbars, which is the GUI interface. What you've described is identical to, say, "xterm -e vim", so, TUI.
  - Karunamon 4y ago
    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.
    - imbnwa 4y ago
      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 https://github.com/folke/which-key.nvim [1]https://github.com/liuchengxu/vim-which-key https://github.com/liuchengxu/vim-which-key