Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

91–100 of 145 posts

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

#91

Post by bjoli »

da39a3ee wrote: post #89
phire wrote: post #6

Earlier quoted context omitted.

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…

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?

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.

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

#92

Post by MontyCarloHall »

chrisseaton wrote: post #90
WhyNotHugo wrote: post #85

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`). And smooth scrolling works on regular neovim with https://gi…

> And smooth scrolling works on regular neovim with https://github.com/psliwka/vim-smoothie 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 N…

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

[0] https://saitoha.github.io/libsixel/

[1] https://sw.kovidgoyal.net/kitty/graphics-protocol/

[2] https://github.com/dankamongmen/notcurses

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

#93

Post by RayVR »

systemvoltage wrote: post #13
lambdaba wrote: 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.

Yes, if they're less than 100ms, sure - animations provide context to what's happening on the screen (human vision system likes to persist objects). Any longer, and I want to throw the computer out of the window.

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.

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

#94

Post by chrisseaton »

MontyCarloHall wrote: post #92
chrisseaton wrote: post #90

Earlier quoted context omitted.

> And smooth scrolling works on regular neovim with https://github.com/psliwka/vim-smoothie 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 N…

> 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? [0] https://saitoha.github.io/libsixel/ [1] https://sw.kovidgoyal.net/kitty/graphics-protocol/ [2] https://github.com/dankamongm…

You mean do all the text rendering yourself and stream the image to the terminal? At that point why use a terminal rather than a graphics window?

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

#95

Post by sagarm »

da39a3ee wrote: post #89
phire wrote: post #6

Earlier quoted context omitted.

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…

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.

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

#96

Post by __s »

chrisseaton wrote: post #90
WhyNotHugo wrote: post #85

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`). And smooth scrolling works on regular neovim with https://gi…

> And smooth scrolling works on regular neovim with https://github.com/psliwka/vim-smoothie 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 N…

It's all relative. smoothie scrolls over multiple renders, rather than jumping a page all at once

One line is plenty resolution. What next, you'll ask for subpixel rendering to deliver subpixel smooth scrolling?

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

#97

Post by MontyCarloHall »

chrisseaton wrote: post #94
MontyCarloHall wrote: post #92

Earlier quoted context omitted.

> 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? [0] https://saitoha.github.io/libsixel/ [1] https://sw.kovidgoyal.net/kitty/graphics-protocol/ [2] https://github.com/dankamongm…

You mean do all the text rendering yourself and stream the image to the terminal? At that point why use a terminal rather than a graphics window?

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.

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

#98

Post by dkersten »

yoz-y wrote: post #79
kchr wrote: post #76

Earlier quoted context omitted.

You can have tabs in vim instead of the terminal. Check :tabedit for example.

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.

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

#99

Post by chrisseaton »

__s wrote: post #96
chrisseaton wrote: post #90

Earlier quoted context omitted.

> And smooth scrolling works on regular neovim with https://github.com/psliwka/vim-smoothie 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 N…

It's all relative. smoothie scrolls over multiple renders, rather than jumping a page all at once One line is plenty resolution. What next, you'll ask for subpixel rendering to deliver subpixel smooth scrolling?

Well anyway ultimately this is the concrete advantage of a GUI that was asked about - it can do better than janky whole-line scrolling.

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

#100

Post by ccakes »

alpaca128 wrote: post #58
lbotos wrote: post #31

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.

Can you explain why I'm supposed to "pre-order" a license key for a Vim-like editor that doesn't yet support .vimrc files? How is it better than this with NeoVim's LSP and treesitter support?

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.

Post reply on HN