Why don't you use a GUI & how can GUIs change that?

So this is something I’ve wondered/thought about a fair bit, and in asking people about it (on Matrix or wherever) I’ve gotten varying responses, but most of the time it’s nothing more than “the terminal just works for me” or something of that sort. Perhaps some people will say using different fonts in different windows or image support or something, but most of the time it’s simply that they prefer the terminal. Which is fine, but it’s not very actionable for a GUI author/maintainer.

Thus I thought I’d make this to see if we can delve deeper into the why people don’t use GUIs (if they don’t), figuring out the exact reasons why many still prefer the terminal, and also so we have a place for discussing new GUI features (although this might be better suited for another post, we’ll see).

So, if you don’t use a GUI, why not, beyond just “I prefer the terminal” or similar? What can GUI authors/maintainers add or change etc. which would entice you to switch, or (ideally) make you switch?

And for both those who use a GUI and those that don’t, what sort of features should GUIs (whether ones already in existence or ones that have yet to be created) add/have which they don’t already? Any ideas?

7 Likes

I never used GUI yet, I should look into it,
the reason I didn’t bother doing it is that I always have Terminal open for me, I just want to jump into editor then quit ease

If the GUI just renders characters and decorations in a grid then there isn’t much use. Smooth scrolling and cursor animation is aesthetically nice but not that big of a deal.

Potentially having some key combinations (C-Tab for example) be unlocked due to not going through the terminal is useful, but not backwards compatible so I’d be weary wary of using it.

What you’d want is being able to render more complex things. Floating windows at non whole number increments, proportional fonts, rendering pdfs, images, graphs, math equations, fonts of different sizes at the same time for markdown/latex.

Also underrated would be having a alacritty/kitty level terminal emulator embedded into the GUI and used for terminal windows inside neovim.

As a tiling window manager user i like using terminal nvim because it doesnt open/close a new window that disturbs my layout. So in some sense i don’t want a neovim GUI, i want a terminal emulator that has all the features necessary to do neovim GUI things but embedded in the terminal.

4 Likes

About me: I use a GUI frontend for long-running work, and I use the terminal for quick edits (e.g. Git commit messages), as well as when I’m SSH’ed into a server and I can get Neovim installed (otherwise I use the system’s bare vi).

As you pointed out in the OP, I think some people really just like the terminal. In my experience, something like 80% of the time if you ask “why don’t you use a GUI app?”, the answer is one or more of:

  • I have everything at my fingertips on the command line (literally)
  • It’s easier to deal with environment variables and working directories if you start your editor from a shell
  • My terminal already has the exact colors/fonts that I prefer
  • My terminal/screen/tmux is my primary window manager
  • I do everything else in the terminal anyway (see e.g. r/unixporn)
  • Startup is slightly faster / less visual jumping around to a new window
  • The TUI is more portable than a GUI and I can use it on both my servers and my workstation

In light of those answers, it seems like the TUI and GUI are mostly serving different categories of users (or different use cases for a given user), and I’m not sure that convincing people to switch even makes sense as a goal.

However, I agree with @indianboy42 that the GUI can and should offer more than just a window to display the same content as a terminal (and I really like/want all of those suggestions). But I think features like this would mostly make Neovim more attractive compared to other editors (VS Code, Sublime, GUI Emacs, gVim), rather than making Neovim GUI more attractive to Neovim TUI users.

My Neovim-Qt setup looks a lot like the TUI, because I think the Qt widgets look ugly and out-of-place (I also don’t use smooth scrolling). But I don’t think that should be the default that we present to someone who is thinking about trying a GUI.

There are also some notable deficiencies in Neovim-Qt specifically compared to the TUI, especially that you can’t use the mouse to copy and paste text that is displayed outside of a buffer. This includes the contents of the command line, tab line, and status line. I consider this a bug in Neovim-Qt (and it also doesn’t bother me much), but if you’re trying out the GUI for the first time, it would seem like the GUI is actually less capable than the TUI.

Some key combinations are still hard-coded to be “synonyms”, even with GUI frontends, such as <C-M> and <CR>. This is an annoying and frustrating limitation; I would very much like to use <C-M>, <C-H>, etc. for other mappings.

I am hopeful that Neovim will one day free us from this kind of silliness!

Side note: You probably meant “wary” and not “weary”. I think this spelling error has become common in English, because of how the word “wear” is pronounced. “Weary” is pronounced “wEEry” (like “week”) and means “tired”. I don’t mean any disrespect by this :slight_smile: Just trying to be helpful.

1 Like

I am simply unaware of the problems that a gui would solve in the context of using neovim in the terminal.

Currently I’m using Kitty as my GUI, even though I don’t use Kitty as my main terminal, because Kitty has great font rendering and lots of nice features. Remote control, for example, allows me to control it from inside nvim. I usually only launch nvim from the terminal to edit config files or commit messages.

Features I miss most from currently available GUIs:

  • Smooth font rendering.
  • GUI font features like undercurl, which most GUIs don’t implement right.
  • Relatively fast startup.
  • Single global status line.
  • External popup/floating windows, with support for real borders.

Things I don’t care about:

  • Animated cursor jump.
  • Integrated title bar.
  • Markdown previewer.
  • File drawer.
1 Like

Sometimes the simplest explanation really is the best. For me personally I don’t see what a GUI could do that I don’t get from a terminal, while at the same time there are a number of things the terminal does that a GUI would not, or at least not without manual fiddling.

Back in the Vim days the only real killer feature I could find in a GUI was the ability to change the cursor depending on the mode, but Neovim has that out of the box. On the other hand, when I start Neovim in the terminal it inherits the working directory, the parent shell and environment variables. Since I do all my work in a terminal anyway I get all of those things for free.

Another very big advantage for me is the ability to SSH into a machine and use Neovim from there. I have a laptop from my employer, but I really don’t like working on it, so when I am at home I use my personal computer to SSH into the office computer. This way none of the work file every leave the work machine. I could run a GUI application over SSH through X-forwarding, but that never feels quite right.

What could a GUI offer? Personally I cannot think of anything. There is eye candy, but that’s nice to have, not something I really need. I guess having an embedded web view or PDF renderer would be really nice. I am using a tiling window manager, which is pretty nice, but it has its limits. If I wanted to have my PDF renderer take up one quarter of the screen and Neovim three quarters I cannot do it. This would require Neovim windows to be actual windows and not just sub-divisions of one window.

I would say I’m a fairly experienced vim/neovim user who has preferred the terminal since I started using vim around 7.2. I never used gVim, but when I temporarily started using emacs (circa 2015-2021) for orgmode the things I was most impressed by was (that would be facilitated by a GUI):

  • the tight integration of pdf markup via pdf-tools
  • inline latex/image previews in notes
  • rendered markdown (IMO this should not be discounted as I often make minor aesthetically suboptimal choices when designing markdown for documentation that I would have caught earlier with inline preview)
  • the ability to preview HTML email
  • the ability to embed X applications

I care predominantly about the first 3. Things like animations, smooth scrolling, etc, are all anciliary to me.

The other main important feature (to me) that is currently missing from the TUI (albeit not for long) is the ability to remotely attach to a remote neovim instance. I believe goneovim implements this.

2 Likes

I’d love a real floating window with borders that isn’t limited by how grid rendering works. Also, a rendered markdown using proportional font would be great.

I mainly want these two things because I really like how vscode / atom / other GUI editors render a floating window filled with markdown from language server.

Compare these two for example:

The second image looks nicer to me. I think Uivonim does this but the performance is… yeah, Electron

4 Likes

I use a remote server via SSH and have a tmux session running there. I keep the session going for months at a time (basically only shut it down if the machine needs to reboot for updates).
The LSP server I’m using takes ages to start up on my codebase, so that is not something you want to go through every day.

To be able to use a GUI on my machine I would need to be able to connect it to the remote server, and preferable run neovim in a daemon mode on that server so I can reconnect to it without having to set it up again.

Besides GVim which I used at the beginning, none of the Neovim GUIs I tested worked ok for me. All had some issues, glitches, or just something that doesn’t work so good.

Also, one thing that’s a bit annoying for me is that I have to add an additional configuration (or have a separate one) for the GUI version. I would love to use exactly same configuration that I use for TUI. Maybe some of newer ones support this, but I didn’t really test any of them recently.

1 Like

I don’t know of any that integrate with WSL, similarly to vscode. That would be a killer feature for me

At least Neovide should support this? GitHub - neovide/neovide: No Nonsense Neovim Client in Rust

1 Like

Looks promising! Unfortunately the release from March doesn’t seem to be working for me - it doesn’t register inserts, and only redraws when I press esc, i, and :. Might be fixed on master, but I’m on a resource limited machine and don’t want to build from source. I might give it another go when they do another release or start doing nightly builds.

I am a long-time GUI user (MacVim and then VimR for nvim) switching to terminal. The reasons are:

  • Both MacVim and VimR have been unreliable in terms of providing access to the latest features. Currently switching because I want to use 0.6.0 nightly releases for the best treesitter experience possible.
  • Virtually every available GUI seems to be some kind of hobbyist project liable to abandonment or slow updates.
  • GUIs often have relatively poor documentation (in English at least)
  • GUIs other than MacVim and VimR always seem to have some weird, glitchy behavior on the edges.
  • The GUI-specific features offered (e.g. code minimap, file explorer) are not compelling to me.

That said, I think a GUI for NeoVim could potentially be amazing. Pretty much everything suggested above sounds great, but here’s what I would like most:

  • Reliability. Number one most important thing. No weird bugs or behaviors. Should have the ability to operate nearly identically to a terminal nvim, and should keep pace very regularly with new neovim releases. Reliability must be communicated clearly on the website/GH repo/docs for the GUI, because the larger the user base of software, typically the better-maintained it is, and it will have a larger user base if it screams “reliable”.
  • Beauty. I stare at the editor for many hours a day, I would like it to look beautiful. Most NeoVim GUIs basically look like terminal. VSCode can be a source of aesthetic inspiration.
  • Notebook rendering/editing. I would kill for a Neovim GUI that let’s me work with Jupyter notebooks. I already use VSCode with the vscode-neovim extension for this, but naturally it’s a bit rough around the edges.
  • Markdown/arbitrary preview. Would like an API for viewing arbitrary rendered output, markdown is just one case.

Really I’m after something like a data science IDE built on top of neovim, but that’s probably beyond the scope of what you’re working on.

1 Like