A standard GUI?

Neovim
1

I’m a Neovim newbie. Please don’t be offended by an outsider’s perspective. There’s a tool I want to use that’s only available for Neovim, not Vim. And Neovim seems like a generally better Vim. So I would love to use Neovim. But I also want to use a GUI. And that is frustrating. (I imagine that there are others like me.)

For me, running in a GUI is a practical need. I use Vim in terminals, too, but for sustained work I want scrolling with a trackpad, cutting and pasting to other apps, being able to drag dividers between internal vim windows using a mouse, and other GUI features.

It seems to me that at present:

Having too many would not be a problem if it was easy to find one that suited one’s needs, but it’s not:

  • Many of the GUIs won’t build on my system (or maybe they would with some effort–I am willing to put in the effort–but I can’t tell whether it’s worth it, because…)
  • Some of those that build won’t run.
  • And some of those won’t run well.
  • And some of those that run well lack basic features that I want.
  • Or have most of the features I want but still have significant bugs.
  • And existing lists of GUIs don’t give me much help in figuring whether it’s worth trying out a GUI or not. So far, none of the ones that seemed worth trying have been suitable for me.

I don’t fault any of the GUI developers for this! Not their fault. It’s understandable:

  • There are so many GUIs that each GUI is maintained by one or a few people.
  • These (generous) people are busy, and a Neovim GUI is probably a hobby project, so the developers might not have time or interest in adding lots of features that they don’t personally want, or even to fix bugs that they don’t encounter.
  • There are so many GUIs maintained by one or two people that many of them have been abandoned (because people are busy). [I know of one that’s a commercial project, but it’s been abandoned afaics.]

So there are lots of people who’ve put in lots of time and energy working on a Neovim GUI–yet it’s still difficult to find a good GUI for Neovim (at least for me). It seems wasteful, although I’m sure that each developer enjoyed developing their GUI.

You might think that the apparent lack of good GUI options is not much of a problem, because (I would guess) most Neovim users don’t use GUIs and don’t care about them. However, that might be because the people who want a GUI don’t use Neovim–because they can’t find a good GUI. (If that’s true, then the lack of a GUI is hindering the growth of the Neovim community. Which is OK, I guess. But I still want to use Neovim, in a GUI. So it’s a problem for me.)

I feel that there ought to be a single, or a couple of Neovim GUI projects, probably as part of the Neovim distribution, that many of the Neovim GUI developers can contribute to. That would require a lot of work on what features to include or not, etc.–that’s extra work–but it also would mean that people can work together on a project, leave the project when they need to without it being abandoned, and see the GUI get gradually better. The work wouldn’t be wasted by creation of many GUIs each of which might satisfy only a few people
each. And those who want their own GUI with other special features can still make one.

The resulting GUI might end up seeming bloated with features, but it might please a lot of people. (The MacVim GUI that I use has all sorts of features that I have never used and that I will never use. I don’t care. It has features that I use all the time.)

That’s my thought. I’m sure I’m not the first person to have it. I thought about submitting an issue at the Neovim repo about this. That seemed silly without discussing it with others first. So that’s why I’m here. Thanks.

2 Likes
2

Unfortunately the way FOSS works is you need to find people that fall in the center of the “skillset”, “free time”, and “motivation” triangle, and there just is not anyone in the core neovim team that fits those categories for an official GUI.

Also, one thing to note is that (at least I) do not feel motivated to increase the number of neovim users, I would rather work on improving features that users that like neovim enjoy, rather than trying to expand the pool of users. We are not a company, so more users does not really improve neovim in the same way more customers would.

3 Likes
3

(The MacVim GUI that I use has all sorts of features that I have never used and that I will never use. I don’t care. It has features that I use all the time.)

If you’re on macOS, what’s wrong with GitHub - qvacua/vimr: VimR — Neovim GUI for macOS in Swift? That’s as close to a “stock Neovim GUI” as you’re likely to get.

4

Thanks @clason! Suggestions like that are much appreciated.

VimR has definitely been the best GUI Neovim GUI for me that I’ve found so far. There are still some things that are important to my normal way of working that it doesn’t quite do. I submitted a couple of issues about these things, so that may change. (Unfortunately this is not a good time for me to learn how to contribute to VimR on those issues. Not sure that I have a good background for that without seriously jumping into Swift, etc.)

Thanks very much also to @mjlbach for clarification of the situation.

5

A few more thoughts.

Yes! I completely understand and respect that. It’s an important point in general–and I have neither the skillset nor time to work on a GUI for neovim.

Yeah–I completely understand and respect that, too.

But for whatever it’s worth, I am one of the people who likes neovim. I don’t have the commitment and affection that comes from long use, but from everything I know so far, I prefer neovim over vim (but for me, I need a GUI that works smoothly for my needs). But of course that is not a reason that you or anyone else on the core team should invest their free time in providing features that don’t interest you and them. I get that.

 

My thought was that since there others who like GUIs for neovim, and there are people who have appropriate skillsets for developing them–people who’ve already invested time in developing neovim GUIs–maybe some of these neovim GUI developers could be incorporated into the core team. Or maybe, without changing the core team’s projects at all, some of the GUI developers could coalesce around a project to build one or two standard GUIs for neovim. Maybe it would even help if there was encouragement or some kind of official imprimatur from the core team. But I really don’t know whether any of this makes sense in terms of how the neovim community works in practice.

6

Such is the fate of FLOSS. In the early days a lot of people got overly excited and started making GUIs simply for the fun of it, only to abandon them halfway through for whatever reason. Maybe the novelty wore off, maybe they lacked the time, or maybe they found that a GUI offers them no real advantage. The hope is that eventually over time one or two projects will bubble up from that chaos and everyone will then rally around them. The fact that this hasn’t happened indicates that there isn’t much interest in GUIs.

Personally I cannot think of anything I would really need from a GUI. Being able to have different font sizes and display images would be neat, but it’s not something I would actually use on a regular basis. I used to use MacVim for its ability to have a different cursor in insert mode, but Neovim can do that in the terminal as well.

I can do all those things in terminal Neovim as well. Have you tried set mouse=a? My terminal is Alacritty on GNU/Linux with X11. For copy and paste to the system clipboard you have to use the + register.

I could have sworn that there was a GUI under the Neovim organization that uses Qt. Maybe I am misremembering things?

7

I could have sworn that there was a GUI under the Neovim organization that uses Qt. Maybe I am misremembering things?

Neovim-qt (which is an external project) is bundled with the official Windows distribution – maybe you were thinking of this?

There’s also GitHub - neovim/python-gui: Proof-of-concept Nvim GUI. Not maintained., which I don’t have to comment because the link title says it all :wink:

8

The lack of a polished neat GUI saddens me too. I heard vimR is good on mac. I was surprised last time that I checked GitHub - equalsraf/neovim-qt: Neovim client library and GUI, in Qt5., it does keep up and is solid.
I like neovide (GitHub - neovide/neovide: No Nonsense Neovim Client in Rust) the most but it’s unusable for me yet (keyboards issues etc).
GitHub - akiyosi/goneovim: Neovim GUI written in Golang, using a Golang qt backend is good once configured too.
I had lots of hope for Oni ( GitHub - onivim/oni2: Native, lightweight modal code editor looks great) but they gave up on neovim (from the little I gathered, they tried to do a lot and the project now sees little activity) :’(

One aspect to consider is that while many GUIs were created at the start, the neovim UI protocol might not have been as good as today and it forces a workflow that may be unusual. We’ve had past contributors create https://helix-editor.com/ and GitHub - lapce/lapce: Lightning-fast and Powerful Code Editor written in Rust .

1 Like
9

Ah, that’s very nice. Thanks, no, I didn’t know about Alacritty. Just tried it on MacOS, and it seems to work the same. Thanks for the historical perspective on GUIs, too.

Didn’t know about set mouse=a, either, which apparently is in vim too. It does a lot. In both iTerm2–my normal MacOS terminal–and Alacritty, and in both vim and nvim, set mouse=a causes trackpad scrolling to work properly, as well as making internal window dividers draggable, and allowing one to click to place the cursor. (Alacritty also allows a (different kind of) trackpad scrolling even without set mouse=a.)

One thing I use a lot in the MacVim GUI is programmatic resizing. I didn’t mention that before. I’ve defined commands to make the Vim window extra wide or 80-columns, etc. I use those all the time. The Neovim GUI I’ve been using the most experimentally is VimR, and it doesn’t implement the vim commands that do that: winsize, set columns, set lines.

However, your comments about Alacritty got me thinking and experimenting. It turns out that although winsize, etc. don’t work in VimR, they do work when nvim (or vim) is run in iTerm2. I’d just never tried it. They don’t work correctly in Alacritty in MacOS it appears, but that’s OK for me, since I can use iTerm2.

So the bottom line is that it may be that in fact I can get everything I want more easily in Neovim in a terminal than in any Neovim GUI I’ve tried so far.

Which is weird–it’s not what I expected. But thank you! Likewise to others who have commented.

10

Thanks @clason and @teto. I’ll try some of those GUIs, even though running in a terminal now looks very promising. Very happy to have the GUI suggestions. There are about 35 Neovim GUIs, and though I can rule out some of them right away, there are too many to make it profitable to try them all. (goneovim was one of the ones I tried and rejected, but I don’t remember why. Maybe I just need to configure it differently.)

11

we also have a magician that does some neat stuff in TUI check out GitHub - sunjon/stylish.nvim: Stylish UI components for Neovim

12

Yup. And now you know why people rarely care about Neovim GUIs :slight_smile:

Yeah, that’s probably what I was thinking of.

13

That’s nice–not essential, obviously, but at some point I might like to use the popup menu to choose between options that I deal with regularly. I am sure there are other ways, but I don’t mind something that looks nice and is convenient to use, if it’s easy to set up.

14

I second this. I am a windows user and most of issues are because of the bad terminal implementation.
Windows Terminal is way behind in terms of terminal standards. It doesn’t handle undercurls and font rendering is bad. Alacritty on windows uses an old implementation of terminal layer(and is refusing to change it) leading to incorrect mouse handling and random slowdowns. Even wezterm uses the same process as Windows Terminal underneath it and hence suffers from same issues.This is a common theme with most terminals on windows.

Relying on nerd fonts for decorations feels hacky as you need to find the correct combination of font , size and weight for it look correct. This might seem like a small issue as it doesn’t hinder the code writing experience but this is just an example of how relying on external terminal and fonts can cause inconvenience. I have tried alot of other neovim GUIs but they too struggle with font rendering and random crashes.

I understand that this exact reason is why neovim is not targeting GUIs as getting rendering to look right on all platforms takes time and effort.

15

Your problems on Windows, @luiq54, sound more frustrating than mine on MacOS. But after thinking that running neovim in a terminal was a good solution, I’m still unhappy with the situation.

In all three terminals that I’ve tried so far (iTerm2, MacOS Terminal, Alacritty) nvim+terminal produces undesirable results with either colors or fonts, even though I’m setting the font to be exactly the same font and size, and the colorscheme file is the same. (In some cases the correct font is selected for the terminal, but it’s rendered thinly. In some cases the colors are shockingly different from the MacVim GUI. Alacritty does best with font and colors, but doesn’t implement other functions I want.)

By contrast, all of the neovim GUIs I have tried recently (VimR, nvim-qt, goneovim, neovide) render the fonts and colors exactly like MacVim. (But again, the nvim GUIs don’t behave properly with some functions that I use routinely.)

That doesn’t mean it’s impossible for me to get a good result with nvim in a terminal with tweaking of the terminal config and nvim config, perhaps with some other terminal application, but it’s been frustrating. I don’t know whether I’ll succeed. I’m getting tired of trying. The fact that the fonts and colors just work, as expected, in all of the GUIs … sigh.

So I guess I’m back in the “Neovim-deserves-a-full-featured-GUI camp.” :confused: (If not one GUI for everyone, perhaps one for each of the three popular OSes.) OK, I’m not sure I ever left that camp, but I was open to the idea that a GUI isn’t needed.

It’s difficult to enumerate all of the reasons that a GUI might be preferable. There are lots of reasons, and in any given use case, many of them might not apply, or in many cases a user’s needs can be satisfied without a GUI. But there will probably continue to be cases for some users where only a GUI will do the job sufficiently well. (I know, it’s FOSS, and you can’t please everyone in all ways, but … some of the remarks in my OP still apply. And I’m not going to be the one do it, so it’s just a wish.)

16

I know it’s yet another program, but I would suggest trying out wezterm. I was a long term Alacritty user on Linux (no pun intended) at the time when I was issued a Mac for work, and unfortunately I found that it was barely usable for me due to the obtuse way in which MacOS handles windows (and the lack of any window management features in Alacritty). I tried iTerm2 and didn’t like it, but then luckily I found wezterm: it has just about more features than I actually need, it is fast, and in my experience it handles font rendering better than both Alacritty and iTerm.

17

Thanks much @donbex. I appreciate the suggestion.

Just tried it. I had hope. But it doesn’t respond to vim/nvim window size changes commands, such as winsize. Or rather, something happens, but it only happens in nvim, and it’s a mess because WezTerm didn’t help out. (Unless that’s turned off by a config option, but I don’t know why that would be.)

It’s kind of shocking to me that any terminal does respond to an editor saying it wants a different window size. Why should an editor and a terminal talk to each other about the size of the terminal? But some do.

18

Updating my fretting, in case anyone’s interested, again with respect for Neovim and all of its benefits, and the work that’s gone into it. That’s why it matters to me.

One consequence of the fragmentation of GUI development for Neovim seems to be that many of the traditional GUI commands that are documented in :help gui are simply unimplemented in GUIs, or are implemented but with an interface that’s different from the Neovim’s gui.txt and is different in different Neovim GUIs. (gui.txt is inherited from Vim, but plain nvim implements many of these commands, and they work when nvim is running in certain terminal apps. It’s just the GUIs that usually don’t implement them.)

I think I’ve now tried all of the Neovim GUIs that seem like they might work for me. I’ve settled on a couple that are most promising for my needs, submitting issues where it seems worth doing so. But it’s still frustrating, and I might just stick with MacVim. I could go on and try an equal number of terminal apps, and play with configuring each one to see if I can get the combination of features that I want. You can only spend so much time on something that won’t necessarily succeed, though.

19

I’ve noticed that Goneovim responds well to “set lines” and “set columns.” It also does a decent job with colors and fonts (the latter of which have to be configured separately). What are you missing with it?

20

@engeljh , yes, that’s true now! I’ve been using goneovim a lot. The maintainer @akiyosi was very helpful and responsive to issues I submitted, including one about set lines and set columns. Previously these commands half-worked, but the window size didn’t change. Akiyosi fixed that.

I also contributed a Goneovim-specific version of winpos with a bit of help from Akiyosi (my first time working with Go and Qt). That’s another gvim function that’s important to me. It turns out that Neovim doesn’t support winpos internally, so Neovim GUIs need to add their own versions of it.

Akiyosi also pointed me in the direction of information about how create keymappings for some gvim keymappings that I had been missing, and I added a tip about how to do that to goneovim’s wiki. And yes, the colors and fonts in goneovim work well for me.

There are still some things I prefer about gvim, so I use both goneovim and gvim.

I’m also grateful to igorgladkoborodov, the maintainer of vv, who also fixed set lines and set columns recently in response to an issue. vv already had enhanced winpos-like functionality, and fonts and colors that I like. I’ll try vv again when there’s a new release, but it’s not so urgent for me that I want to set up the development environment.

(One thing I like about gvim is that I can increase/decrease the font size with Cmd + and Cmd - . Goneovim doesn’t have that yet. vv does. The Cmd+/Cmd- behavior in vv is different from the way it works in gvim, but perhaps the vv way is better.)