Live data from Hacker News

Nvui: A NeoVim GUI written in C++ and Qt

github.com

131–140 of 145 posts

Re: Nvui: A NeoVim GUI written in C++ and Qt

#131

Earlier quoted context omitted.

What problem? It’s their repo—they can add what they like…

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 obso…

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.

Re: Nvui: A NeoVim GUI written in C++ and Qt

#132
post #8

The window animations are really nice: https://github.com/rohit-px2/nvui/blob/main/assets/display/v... 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.

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.

I recommend that you try webp instead of gifs. they will probably look better.

Re: Nvui: A NeoVim GUI written in C++ and Qt

#133
post #27

Earlier quoted context omitted.

Happy to see they finally ported from vulcan to openGL[1], but it's not released yet. https://github.com/neovide/neovide/issues/491

> 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?

Vulkan is a side-grade to OpenGL. For games, Vulkan is the best tool. For a text editor, OpenGL is the better of the two. Very different use cases.

Re: Nvui: A NeoVim GUI written in C++ and Qt

#134

Earlier quoted context omitted.

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 th…

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,…

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.

[1]: https://rtyley.github.io/bfg-repo-cleaner/

Re: Nvui: A NeoVim GUI written in C++ and Qt

#135
post #125

Earlier quoted context omitted.

I don't always use :make. Navigating manually is fast: Specific lines is just :NN, jumping to an open buffer is just :b substr . 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 throu…

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

Re: Nvui: A NeoVim GUI written in C++ and Qt

#136
post #35

Earlier quoted context omitted.

> 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 i…

That's a really nice a distinction! Thanks

Re: Nvui: A NeoVim GUI written in C++ and Qt

#137
post #135

Earlier quoted context omitted.

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

Re: Nvui: A NeoVim GUI written in C++ and Qt

#138

Earlier quoted context omitted.

Last I checked Github doesn't support embedded videos. 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...

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.

why don’t megabytes of gifs belong in git? you can use things like git-lfs if you don’t want the file updated with every change.

Re: Nvui: A NeoVim GUI written in C++ and Qt

#139
post #78
post #57

Earlier quoted context omitted.

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.

Would you care to elaborate a bit? I think both Emacs and Vim have valid use cases, and I am interested to hear your opinion.

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.

Re: Nvui: A NeoVim GUI written in C++ and Qt

#140
post #54

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…

> Too much of my work happens remotely. ... You know that GUI apps are able to edit code over SSH too, right ?

I have been using sshfs to give local editors access to remote files. Are you suggesting a better way?
Post reply on HN