Hacker News Reader

Comment by yakubin | Hacker News Reader

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.

View on HN

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.

https://github.com/neovim/neovim/issues/8715

As that issue points out, "gj" and "gk" will step through by visual lines.

The complaint in that ticket is that you can't make it the default for all the other ways of scrolling

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.

This is about _scrolling_ visual lines. Navigating them as you say, is just fine.

Ah, got it, right. Sorry for the noise!

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.

I've found that to mainly be a problem with syntax highlighting. Turning it off speeds it up significantly.

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.

[1] https://github.com/neovim/neovim/wiki/Related-projects#gui [2] https://github.com/qvacua/vimr

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.

[1]: <https://github.com/neovide/neovide>

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

[0]: https://neovim.io/

What "GUI" things do you miss from GVim?

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

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.

It's probably not what you're looking for but I find vim bindings for VSCode is a good balance between vanilla vim and an IDE.

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.

for the chaotic evil play I was going to suggest Emacs with vim bindings. But you outdid me there.

Why not GVim?

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.

When your are working with huge files or files with huge lines it makes sense to disable syntax highlighting to improve performance (:syntax off).

If you use neovim with tree-sitter, this is not really true anymore! Or at least it extends the huge file/huge line boundary pretty far.

Tree sitter is amazing. It even works really fast on huge minified files.

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.

Reply on news.ycombinator.com