If Vim was a GUI application (and could smoothly handle long lines), it would the perfect editor for me. Alas, the best I've seen so far is Neovim's discontinued GUI frontends.
What's wrong with the way it handles long lines? It can either wrap or not wrap depending on your configuration. Personally, I disable wrapping in every editor I use because I find it extremely off putting. I'm curious which behavior you desire and if you have any examples of editors that you think handle long lines well.
Another issue is scrolling visual lines one by one that have been wrapped. (N)vim can only scroll by literal lines, so if a line is longer than the screen and wrapped, there is no way to step through line by visual line.
That’s strange. I just tested it and both GVim on windows and vim on a vps linux terminal have no problem with going anywhere on a 170k long line. It lags a little but visually is fine.
And just in case you missed it, you may gj gk to navigate visual lines or remap j, k (and <Up>, <Down>) to gj gk to make that default.
I have a genuine question why use nvim at all if it has such issues with presenting text in a window.
Performance. I mean really long lines, not merely lines which exceed window width. Vim is a bit better at that than Emacs, but it still slows to a crawl on some large lines. Sublime Text e.g. never has any problems with long lines on the other hand, no matter how long.
With wrapping or without? I occasionally use vim to open up minified JavaScript files to follow stack traces when sourcemaps are broken. I'll open the file and do something like 515328l (go 5153281 characters to the right) to get to the correct place and have never had issues.
When we broke our sourcemaps for a bit, I was the dedicated human source map for a while and vim was an absolute life saver.
Which discontinued Neovim GUI do you mean? As far as I know, while there are lots of discontinued ones, there are also several actives ones, see [1]. The "Activity" column in the linked table doesn't always show the correct age, e.g. vimr [2] is at least three years old.
I was mostly thinking about Neovide[1], which is active, but I've read somewhere that Neovim was planning on not supporting this idea (of multiple GUI frontends) and that they were going to focus on the terminal UI. Maybe that was wrong though, since it's still listed on the Wiki you linked, and Neovide is still getting new commits.
Neovim is not developping GUIs themselves, but they are actively maintaining the API these GUIs use. It's even listed as a feature on their homepage[0].
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.
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.
I use it as well, it is not 100% compatible, but all the main features that I need (basic things) works fine for me. If somebody stuck with vscode but wants vim key bindings I hightly recommend to try it.
What I noticed that people build "their own" IDE installing and configuring third party plugins and spend a lot of time to maintain this configuration. And there is no guarrantie it will be better then what is already supported in vsCode for example. So as an alternative one can go other way around and just install vim plugin.
It's just a terminal really, 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.
Neovim is teen-cool, but seemingly gui was not their priority at all for years. Unless you’re trying to configure vim as vscode for some reason, don’t bother yourself and use gvim on linux/windows or macvim (mvim) on mac.
Or maybe I’m missing something here too, what “gui” means for you?
Edit: oh I see from other comments. No, this type of gui vim doesn’t do.
