Nvui: A NeoVim GUI written in C++ and Qt
github.com
github.com
I wonder if it's possible to reduce duration slightly. Personally I find animations useful and a great improvement to UX but I prefer as short durations as possible. I also set 0.5x animation duration / scale on Android and it makes it feel much snappier, but don't like outright disabling them.
Any longer, and I want to throw the computer out of the window.
(a) GIF is not the right format here, use a video format because it’ll produce a visually superior result (proper colour, no dithering needed—not that it actually is even with animated GIFs) and much more usable result (not autoplaying if the user agent’s configuration says not to, allowing scrubbing, showing how long the video is rather than you having to guess “is it still going, or did it start again?”, that kind of thing) in significantly less space.
(b) Things like this emphatically do not belong in the code repository, because they bloat things forever despite being for demonstration only. A repository that would have been 1.0MB and cloned in well under a second is instead 46.2MB (43.8MB of GIFs and 2MB of PNGs) and took me about fifteen seconds to clone (cloning repositories from GitHub is always slower than you’d expect when you’re on the other side if the world, in AU/NZ).
It's far from ideal, and I doubt anyone is claiming otherwise, but GIFs in Github READMEs are entirely standard practice.
EDIT: Well, there you go. Video was introduced within Github this year: https://github.blog/2021-05-13-video-uploads-available-githu...
EDIT: didn't think I have to clarify this, but when I say put a screenshot, I mean "A"(1) screenshot, if necessary.
The compromises being made in bloating repositories because GitHub presents the README as project info rather than at least allowing you to separate it are painful.
Why should the entire project not be subject to version control? It's a well established industry best practice.
Reproducible documentation is just as important as reproducible builds.
There's likely a strong argument to be made for Git sub-modules though i.e. putting the documentation in a sub-module.
You can rewrite history on the media branch so the files don't accumulate whenever you update them.
I found this idea here: https://medium.com/@minamimunakata/how-to-store-images-for-u...
Also about the dithering, I'm aware that the GIFs look horrible, but that was not how they looked when I recorded them, I don't know if it was Github's compression but they look a lot worse when uploaded.
The README transfers almost 100mb. If I'm on my phone with no wifi and I see an interesting repo as I'm a neovim user, I will just lose 100mb from my data plan with no warning. One doesn't expect that when visiting the README of a code repository.
Then what happens when they change something that makes the gifs obsolete? Will they add a commit with updated gifs that doubles the size of the repository? Most developers use
git clone $URL
Anyway, the default animation durations are IMO too long, at least the cursor animation, I couldn't make the window animations work, wonder if it's related to that error message.
[edit] nevermind, I see there's a released build so I'll just use that and go the patchelf route
:NvuiCursorAnimationDuration 0.1
That'll reduce the duration to 0.1 seconds. The animation also runs at a specified frametime in ms (divide 1000 by FPS), default frametime is 10ms (so 100FPS). You can modify this using
:NvuiCursorFrametime 5, for example, for a 5ms frametime (200FPS).
Why are they doing this? And why does it make you happy? I don't know much about the difference, but from what I've seen it seems like a lot are going the other way (OpenGL -> Vulkan). For example, isn't Godot 4 going to be primarily on Vulkan whereas the current version is all OpenGL?
The author complained that using Vulkan and the skulpin library “greatly increased the difficulty for some platforms of installing the correct graphics drivers”
https://old.reddit.com/r/neovim/comments/mvoimq/is_there_any...
I guess my question can be posed to any gui text editor. Still, nice project!
- Splits I can drag around to move and resize with a mouse
- "Native" window tabs instead of terminal-style tabs
- A gvim-style menu bar with some operations for which I can't be bothered to remember the key combination.
So, overall, mostly mouse support and better discoverability. I've tried a few though and haven't really found what I'm looking for, open to suggestions :)
You can already use the mouse to resize splits in neovim, :set mouse+=a
> "Native" window tabs instead of terminal-style tabs
Which features would "native" tabs provide that aren't already available?
> A gvim-style menu bar with some operations for which I can't be bothered to remember the key combination.
Which operations would you put under the menu?
You can sync your system clipboard with vim, for example. This also works well with clipboard history apps like Alfred or CopyQ.
Also, :set mouse+=a solves the line number selection issue.
In ideal world: reordering, tearing off and merging.
> Which operations would you put under the menu?
Ostensibly, all of them?
That's an interesting idea. It sounds like it should be technically possible in the terminal too.
Same would go with drag copying text.
I'm not sure how to handle something like this in a terminal editor, unless the vim plugins are aware of it (but they're not, since they weren't written for it). In a non-terminal editor like nvui, the new window could be just a view into a buffer, but still running inside the one instance of vim, allowing these plugins to keep working transparently, even though now there are multiple windows.
I don't think this is something that's easily possible with terminals without rewriting all the plugins that might need to be aware of it.
The iTerm2/tmux integration show that's you can map TUI windows on to GUI windows including splits into new GUI windows.
It's actually possible to have both the TUI representation and GUI representation connected to the same remote tmux session.
now, that's a good one.
You might want to watch https://github.com/glacambre/nwin
There are a few examples in the GUI based disassemblers world (like IDA pro) which use graphical arrows to show where branch/jump instructions goto. The usefulness of those is enough to convince me that perhaps more research needs to be done in this direction.
There is also the small advantage of being able to have more than one font type/size on the screen. Your navigator panel can be a smaller font size, Your inline documentation viewer can use a variable-width font.
The counter-argument to all that is always: "Is it worth giving up the ability to be used in a terminal to add those few features?"
Everything else can be defined as "style" and gets very subjective. nvui looks like it has nice animations and smooth scrolling.
A very basic feature is that IDEs underlines in yellow for warnings and in red for errors, as well as show fix-it popups when hovering the mouse around the error area I don't believe a terminal can do that while keeping syntax highlighting no ?
E.g. here's a plugin for simple-term to add support for it: https://github.com/hexoctal/st-undercurl
The Kitty terminal has all kinds of graphics addons including coloured undercurls and images too:
https://sw.kovidgoyal.net/kitty/underlines/
Vim and NeoVim both support coloured undercurls too.
I updated some Emacs package recently and now it opens any errors in a list buffer.
Vanilla Vi users would use :make to populate the location list, and then :cn or :cp to navigate back and forth. :cope to open up the quick fix window where you can use all your regular VI keybindings to navigate. Enter opens the location under the cursor in your previous VIM split.
There are also plenty of plugins that add inline diagnostics. It's common to use bindings for navigating these that ape the spell check navigation bindings ]s and [s.
Or, :tag FunctionName (which has completion) to jump to a symbol.
Or, forward incremental search to jump to a string in a file.
I also have a plugin to invoke fzf, (\tb to search buffers and \t to search for files by name), but I don't use it that often.
VIM has many tools to navigate through text. Everyone's got their own preferred methods.
If I don't have the file active but it's open (very likely if I have a compile error for it), then I can foreground the buffer with :b myfile<CR>. Then :17 to jump to line 17.
If the file isn't open at all, either fzf (\t myfile) or just :e path/to/myfile.
The main downside of :make is that it's synchronous, which is why I sometimes build in a separate tmux pane.
Overall I like it a lot.
These are by no means must haves, and there are workable alternatives, but IMO they're nice improvements that warrant the small switching overhead.
Some things I like about neovim over vim.
- Lua integration as first class citizen.
- Treesitter
- lsp built in
- Feeling that the community is super active and in a period of movement.
I love being able to hack and add specific functionality to my own workflow in lua just as part of the editor. I can add features in a way that I just can't in VS Code or vim. It's no emacs level of hackability, but it's a happy medium for me.
I have no knowledge about VSCode's JS nor NVim's Lua APIs beyond that one can write extensions in these langs. Would you be able to expand on what can you do with Lua in Nvim that can't be done in VSCode? That could really be a tipping point for me.
Meanwhile the "hello world" tutorial for extending VS Code starts out with installing Node.js & multiple npm packages and compiling some source file.
For a power user it's just not the same, and there's no way I'd ever switch to another editor without this flexibility.
This[0] post about the early days of NeoVim development made some interesting points about Vim, but one choice quote I recalled and had to google,
> Some of Vim’s source code isn’t even valid text. It’s not ASCII or UTF-8. The venerable file can’t figure out the encoding...
Re-building things to a more solid foundation enables new workflows that are currently challenging. As a Vim user, I have longingly looked at the Emacs ecosystem, with its saner extension language (though Emacs lisp has its own historical baggage weighing them down). Once Lua becomes the default, I expect to see new evolution in features that would otherwise not have made it to the Vim scene. At worst, I can imagine VSCode javascript plugins get transpiled to Lua to run within NeoVim.
[0] https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...
For shell interaction, I use eshell, a UNIX shell written in Elisp, as often as I use anything else. It has some sharp edges, but it takes more sharp edges off shell interaction so it generally makes, for me, the most pleasant way to interact with the shell.
I am aware of no NeoVim project aiming at something like eshell, and it would not, I think, be a good fit for the NeoVim philosophy if it were tried.
Is Neovim flexible enough that it could stop being vim? Remove the modal key-system and implement something of your own? Has enough introspektion to allow something like emacs which-keys? This is a module which show a list of valid keys that can be pressed when you are inside a keychain.
As a result, the plugin ecosystem is exploding. You can find a directory of neovim specific plugins here: https://neovimcraft.com
I've tried NeoVim for a couple of month this year.
It's a tad snappier than vim, but there are a number of "quirks" (behaves ok, but doesn't behave exactly like vim) that made me walk away from it: at this point, vim is so hard-wired in my brain that any tiny difference in behavior is painful.
1. searching for stuff with / jumps prematurely to destination, drives me nuts.
2. I have most "smart" features (auto-indent type stuff) disabled for C++ mode in my .vimrc, which works fine in vim but is completely ignored by neovim. It requires futzing around with post/pre loading of plugins, which - 1.who has the time to do these things 2. makes for incompatible init files.
3. does not read .vimrc by default and requires linking files to have a united init file
I might revisit neovim the day I have enough time on my hand to figure out how to install the whole tresitter shebang.
I always set Vim to jump to the first search result in realtime because that lets me take a glance at another part of the file and then immediately jump back with Esc. So that way I didn't notice this apparently became a default setting in NeoVim. Which is still a weird thing and shouldn't happen imho.
And I always have all kinds of smart features disabled in every situation because almost nothing annoys me more in software, and as far as I can tell nothing changed with the switch.
The init.vim thing is definitely cumbersome when you just want to try it out, even though in the end it's just a symbolic link.
> I might revisit neovim the day I have enough time on my hand to figure out how to install the whole tresitter shebang.
I just did that last week, it's relatively straightforward with the guide in the vim-treesitter readme but requires the nightly build until NeoVim 0.5 releases. And if I'm not mistaken that future version will make it easier too.
can I apt-get it ?
I still use Neovim, but this is my main gripe. Broadly I like it a lot, for reasons others have covered.
[0] https://github.com/rohit-px2/nvui/blob/main/assets/display/v...
> Customizable cursor height (see :h NvuiCaretExtendTop and :h NvuiCaretExtendBottom)
Ex. :NvuiCaretExtendTop 200, :NvuiCaretExtendBottom 100 (see below)I do something similar by setting cursorline and cursorcolumn. It gives me a (more subtle) full-file crosshair showing where the cursor is.
Ive been down the rabbit hole of setting vim’s code intelligence up (ale and all that), in the end it felt brittle and not good (vs perfect completion for golang/typescript in my IDE).
So Im curious, whats the case for going pure windowed vim like this?
Yes, there's still the cost of setting it up in the first place still. That comes with the territory. There are some decent neovim distros out there (lunarvim, nvchad, etc) to get you started though!
Neovim 0.5 now has a built-in language server, and 0.6 will have even more language features available via tree-sitter integration. The best is yet to come.
I find the fact that neovim runs in a terminal an advantage; they share font configuration and colour and other settings, and I can quickly jump in and out of nvim from a terminal.
Having it run in a separate window just means I now have an extra window lying around (the terminal where I typed `nvui`).
And smooth scrolling works on regular neovim with https://github.com/psliwka/vim-smoothie
Maybe you'll find some advantages in having a long-running editor process, rather than starting one from the terminal whenever you want to edit? For example, ctr+click on a compiler error message in the terminal could open the file at the correct line in the (already running) nvui process.
Doesn't 'smooth scrolling' mean scrolling in increments less than a full line, to avoid the janky jarring jump from one line to the next?
I don't get how you can do smooth scrolling in a terminal interface? The screenshots in that link aren't smooth - they jump whole lines at a time, unlike the screenshots you can see on the NeoVim page.
Via a terminal bitmap rendering protocol like sixel [0], or KiTTY’s terminal graphics protocol [1]? I wonder if a library like notcurses [2] could allow for efficient rendering of text to a terminal graphics framebuffer?
[0] https://saitoha.github.io/libsixel/
I agree, it’s an ironic state of affairs that in the era of cloud computing and thin clients (everything old is new again!) TUI graphics might be one of the best way of actually working remotely on those cloud VMs.
One line is plenty resolution. What next, you'll ask for subpixel rendering to deliver subpixel smooth scrolling?
Apple has even dropped subpixel rendering entirely, since that was only really needed in lower resolution displays.
No vim emulation in your GUI editor, but actual vim in your editor.
How is it better than this with NeoVim's LSP and treesitter support?
Not affiliated with the project, or even really a user, but bought a license a while ago to support what I still think is a nice idea.
Additionally, in my mind a terminal serves a similar role as plain HTML web pages - it constrains what can be done and I am extremely used to it, which makes it very easy and quick to use. On the other hand in a GUI editor (or a JS-heavy web page) it feels that it has more possibilities, which allows authors to customize things in ways that I don't expect, which can take away from my focus on what I'm doing. There's also the additional curse that because of these possibilities, authors seem eager to change things more often, whereas I value stability.
... You know that GUI apps are able to edit code over SSH too, right ?
I'm not even shocked anymore, at how out of touch and stuck in their ways some people are.
If this is your workflow: terminal; ssh <remote server>; vim <file>
...