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.
Eww, a 20MB GIF with harsh dithering artefacts. And then another 22MB in two more GIFs. All in the repository.
(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).
I believe the best practice is to use a dedicated "media" branch for screenshots/gifs/webp. Then you can use them on your readme like this .
You can rewrite history on the media branch so the files don't accumulate whenever you update them.
That’s still going to be included in a standard clone, though at least it makes it possible to do a partial clone and exclude that branch. rjzzleep is right to point out the wiki repository as a good place to store such things, still being a Git repository so that it need not be tied to GitHub, but there’s also the option these days of editing the README in GitHub’s web interface and uploading the images or videos through that, which stores it on GitHub servers outside the repository.
Hey, I'm the developer for nvui. I definitely messed up a bit putting the GIFs in the repo, I noticed it when the actions' build size increased by about 40MB (the display assets get removed now in the build). I don't know if there's a way to remove them now without removing a lot of the git history.
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.
You can use BFG [1] or git-filter-branch to remove individual files from the history, though doing so will change the hash of every commit since the files were introduced. Whether it's worth the disruption or not is up to you.
No idea why he's getting downvoted but megabytes of GIFs absolutely don't belong in a code repo. Author could have just put a screenshot in there put the video inside the github .wiki.git repo.
EDIT: didn't think I have to clarify this, but when I say put a screenshot, I mean "A"(1) screenshot, if necessary.
Even the screenshots don’t belong in the code repository, there’s another 2MB in this instance. I think you can still get the README to embed images from elsewhere? And if not, just link to it, “screenshots over here”.
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.
What happens when the URLs referenced by the README stop existing (domain expiry)? What about when the project is forked? What happens when I want to look at old documentation locally?
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.
This particular content isn’t documentation so much as marketing material—part of the shift GitHub has foist upon us in what a README is. But even were it documentation, that needn’t belong in the same place. This is the wisdom of rjzzleep’s suggestion of the wiki repository, an auxiliary Git repository that GitHub already creates for you.
A screenshot or two, sure. And maybe chrismorgan's point could have been, well, perhaps expressed more gently. :) But the general point about multi-megabyte image files that are only there to enhance the README file perhaps not being ideal to have in your code repo, and something you could have on a separate non-repo page that goes into more detail, seems pretty reasonable.
Even when GitHub didn’t support embedded videos, large GIFs are awful enough that I insist that they had no place in READMEs, whether internal or external to the repository. In that time, it was far better to make it a link to something external.
The author deliberately added the files to the repository. That’s (part of) the problem. .gitignore is about saying “I don’t want to add matching files to the repository, so stop telling me they’re not in the repository”.
If it's not a problem, then I would say it's rude for potential users and bad practice for developers.
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
which copies the entire repo history, instead of using `--depth 1`. So now if someone wants to contribute a small change, they have to download hundreds of MBs of gifs.
Hi! I'm the developer of nvui. You were definitely right about the readme bloat. I've removed the GIFs in favor of videos uploaded to Github and links to them, although the GIFs may be stuck in the history.
Hi! I'm the developer for nvui (didn't realize this post was made, never used this forum before). The animation durations and a few other things about them are customizable if you look into :h nvui-multigrid and :h nvui-cursor.
As for the GIFs, I didn't expect them to come out badly (don't know if it was compression, but they didn't look that bad when I uploaded them. I'll look into making a "media" branch.
Hi and thanks! I'm a NixOS user and sloppily created a package but when I run I get "qt.qpa.wayland: EGL not available", probably an issue with my build.
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
Hi! If the animations are too long, you can shorten them. So for the cursor animation, the default is 0.3 seconds. You can shorten it to, let's say, 0.1 seconds by using the command
: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).
I’m not a UI/UX expert but here’s my 2¢ from limited work in this area. It depends on the type of animation and the platform. A fade in that’s 250 or even 500ms can be a nice effect on mobile when it’s not blocking other interactions. 100ms is too short to be noticeable for many things and depending on the screen refresh rate and distance for motion animations you will end up with large jumps.
> Happy to see they finally ported from vulcan to openGL
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”
In general: There are a few theoretical advantages when it comes to doing advanced syntax "highlighting". Not that I've seen any GUI IDE/editor ever do syntax highlighting that couldn't be done in a terminal.
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.
> Not that I've seen any GUI IDE/editor ever do syntax highlighting that couldn't be done in a terminal.
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 ?
If you run your editor in a terminal, how do you do things like ctrl+click on a compiler error in the terminal and have the file opened in your editor at the correct line?
People who prefer the terminal don't click on things much.
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.
So if you issue a compile command in a terminal, outside vim, and the compiler emits something like `myfile:17:7` to stdout, how do you then open vim on line 17 of myfile?
Often I already have the file in question open, so it's just :17 to jump to line 17.
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.
OK cool. I'm certainly a huge terminal user myself and no advocate of increasing mouse usage in general, but for working through things like compiler errors / stack traces etc, wouldn't you agree that, seeing as all the file path and line number is present, we should be able to invoke the appropriate handler with a single UI action (where appropriate handler means "open file at this line")? The number 17 isn't itself of interest, and it shouldn't have to pass through our brains IMO. The semantics should be "open editor at this error" not "open editor at line 17".
I focus the interaction window and press the keyboard shortcut for opening the editor at the point of the error? You don't need a mouse to navigate text.
I updated some Emacs package recently and now it opens any errors in a list buffer.
I have not tried this one yet, but what I'd like to see in a nvim gui:
- 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 :)
"tearing off" to me means creating a new window -- I don't know any terminal which lets you down a new window (although terminal lovers wouldn't want that I imagine).
Yes that's the idea. Tearing off a tab in vim and creating a new terminal window with an instance of vim having contents of that tab. This is possible in vim guis but afaik not in any terminal version.
When I'm using an IDE (vim-based or otherwise), I tend to have other things integrated into the editor session, for example I'm connected to a REPL or other external thing. If I pop a tab out into a new window, I don't want it to be an entirely separate editor session: I want it to keep all these extra integrated things as the parent. I still want to be able to evaluate code in the same REPL session as the parent without having to create a new session or connection.
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.
I want native style tabs and line numbers. By native style, I mean both of them in some way separate from the main code window. When I have line numbers enabled in nvim and if I select code using mouse to copy, line numbers get selected automatically and only way to get what I want is to use visual mode or turn off numbers. Its a bit slower than selecting with mouse for me
Sounds like neovim-gtk has 2/3 (you can resize splits with the mouse, but you can't move them), but unfortunately, it's infrequently updated, sometimes I experience glitches, and it sometimes fails to build.
I like having gvim or macvim as the default text editor to open files when the are clicked from Dolphin/Finder/etc so that I can read and edit the file with vim and my config, rather than whatever the OS default low power GUI text editor is. Maybe I could rig up something to open a new terminal and then open vim in that but vim in a GUI works quite well.
I've been using NeoVide (same idea) for the last few weeks and I've noticed three differences: the colors/font are closer to the intended look, it's got nice smooth (and quick) animations, and it seems like the rendering is faster than in the terminal to a degree it feels more responsive.
What's the elevator pitch for Neovim over regular Vim or GVim? I see verbiage about extensibility and modern guis, but has any Vim user actually seen real world benefit after switching to NeoVim? Is it all just icing?
I am willing to take the philosophical stance that even if NeoVim was only a 1:1 feature parity of Vim, it would still be a GoodThing. We need to find a way to dig ourselves out of endless backwards compatibility and advance the state of software. Supporting 8.3 filenames no longer has its place.
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.
There has been a lot of talk around here lately about modernizing emacs. It really seems to me that neovim is shaping up to be the new “modern” emacs. With full lua integration, lsp, gui clients, and projects like neorg it’s getting a lot closer to building its own emacs like ecosystem.
Is neovim really flexible enough to compete with emacs? Adding just more tooling is not really what would make it shine in emacs-space. My impression is more that neovim is competing with the likes of Sublime Text, maybe to some degree with VS Code.
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.
I like the NeoVim project and think Lua is a great scripting language, and so I wish the project all the best, but it is not attempting to scratch many of the itches that Emacs and Elisp do for many of us old timers.
To choose just one example, but one that illustrates the gulf between the two projects.
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.
Gvim isn't really an "or" in this case, it's just a GUI for vim.
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.
> can add features in a way that I just can't in VS Code
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.
Can't say much about Lua, but the huge advantage both Vim and Emacs have over many other editors: you don't need to write a plugin to add a feature. Plugins are just scripted functions. You can press `:` and define a new keybinding right there while editing a file. Or write a function in the .vimrc and it'll be loaded at every start. Or try out other colors for the UI or syntax elements using the same commands used in syntax definitions. It's all directly accessible to the user with complete documentation in the editor.
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.
On top of 0.5 providing tree-sitter syntax highlighting and LSP support natively, it supports lua. Vim configurations can now be completely written in lua.
As a result, the plugin ecosystem is exploding. You can find a directory of neovim specific plugins here: https://neovimcraft.com
With Neovim 0.5 you'll get native SLP and treesitter support. And it has first class Lua support, which is a huge improvement over vimscript for plugin writers and if you do larger configs yourself.
These are by no means must haves, and there are workable alternatives, but IMO they're nice improvements that warrant the small switching overhead.
I think one of the reasons I switched was being able to have my config in the xdg config spot instead of my home directory. I don't know if oldvim ever added support for that, but both emacs and neovim support it now.
>has any Vim user actually seen real world benefit after switching to NeoVim
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.
What for example? I genuinely haven't noticed any difference out of the box. I usually also don't like deviations, hence why I can't stand Emacs' Evil mode.
There was quite a few, but off the top of my head:
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'm sure with enough work, I can get it to behave the way my poor old stiff brain expects, but - again - who has time for stuff like this.
I might revisit neovim the day I have enough time on my hand to figure out how to install the whole tresitter shebang.
Ah, coincidentally my preferences make the first two non-issues:
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.
There's no official upstream apt repository/ppa, but there is a package in debian experimental (an unofficial but often outdated ppa for ubuntu exists as well, but there's no v0.5.0 in the stable repository). You can also grab a self-contained binary (an appimage) from https://github.com/neovim/neovim/releases/download/v0.5.0/nv... and then rename it to "neovim", mv it to /usr/local/bin, and chmod +x.
If you need another, saving a file using sudo after opening not as sudo is much more annoying and the normal strategy in vim (which often includes `tee` but I prefer to use `mv`) doesn't work at all.
I still use Neovim, but this is my main gripe. Broadly I like it a lot, for reasons others have covered.
If I remember correctly, there was also some problem with Vim’s main maintainer not letting new functionalities merged, effectively freezing the project.
I love vim, but I can no longer see the case for pure-vim (besides devops/infra work where the most basic vim setup is usually enough) in the world of IDEs + Vim mode.
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?
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.
Have you used vim since language servers became a thing? I was in the same boat as you for a while, but I've been consistently impressed with how far the language server ecosystem has come.
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!
I'm suspect about this gui project, but I setup LSP + neovim for a rust project last week and I think it is significantly better than any IDE I have seen, super productive
I don't quite get what the advantage / goal of this is.
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`).
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.
> I don't get how you can do smooth scrolling in a terminal interface?
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?
Remote access is the big one. It’s 2021 and ssh somehow still remains by far the most robust protocol for remote interaction. X forwarding is awful, and VNC and its ilk require forwarding an entire desktop, which is inconvenient if you’re just interested in working in a single application, or having your client machine do its own window management.
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.
I've been trying this for IntelliJ to be able to develop Java on a remote instance and it's intractably slow. Haven't figured out where the problem is yet - I guess maybe IntelliJ does some things that expect performance that the remote file system isn't able to provide.
And why not? Video games are fully antialiased. Why shouldn't I demand at least the same care and attention to technical detail in my productive tools?
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.
I guess this is a thing you could achieve with neovim-remote[1]. My main use case for it avoiding nested neovim processes in the inbuilt terminal, though
The advantage is that there's something for everybody. You like working in a terminal, but I like having a dedicated GUI IDE, and I want it to be built on Neovim underneath. There is a separate config file for the GUI layer.
I'm sorry, I might have been misinterpreting, could I you explain what you mean by actual characters? Even VSCode's minimap draws some shapes, but they're too small to discern any characters.
In VSCode it actually draws the font with very small size. It might look better on larger resolution displays. You can also increase the size with "editor.minimap.scale": 4
VS Code gives you a choice between actual characters and coloured blocks. Actual characters might or might not be discernable, it depends on how large you set your minimap. I personally make mine quite small, so there's no value to actual characters, but if I make it larger, I can make out enough of them to see additional structure.
Reading from the v1 release, there are currently only Windows & Linux support. Maybe you could build it from the source code though. (edit) Building for MacOS doesn't seem to work https://github.com/rohit-px2/nvui/issues/20
If you want a vim GUI, Onivim 2 is usable and doing a Vim GUI slightly differently (made libvim, and is doing the UI in Revery an OCAML offshoot). I've been using it a few hours each week to edit python/ts/js/md and it's worked surprisingly well. This also looks really good, and I'm happy to see next-gen vim get love.
Oni looks nice, but is a non-free program with an EULA so I would rather not use it. However it also states that a release is relicensed under the MIT/X11 license after 12 months from its release.
Onivim isn't trying to be a vim GUI, it is it's own product that is something like VS Code on top of libvim. They opted to go with the VS Code extension ecosystem which necessarily excluded vim extensions.
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.
It seems neat, though I would never seriously use an editor that I couldn't run in a terminal. Too much of my work happens remotely.
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.
These are all valid points, but I don't think they apply here. This is a GUI frontend for Neovim, which is a terminal editor. So yes you can use the the editor in the terminal. This just gives you the option to run the same editor in a GUI for when you need it.
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.