1. 64
  1.  

  2. 11

    Thanks for posting! I wrote this with the help of some wonderful contributors. I’d be happy to work on any feature requests or answer any questions.

    1. 13

      Indeed, I’m excited and impressed at the the contributions to neovide. This is a case where Nvim’s decoupled architecture seems to bear fruit (which isn’t always totally obvious :)–people can fully embrace new ecosystems like rust without being blocked by Nvim’s tech stack.

      Recently https://github.com/equalsraf/neovim-qt/ (c++) has been picking up steam as well thanks to some talented contributors.

      For more on Nvim arch see also: https://lobste.rs/s/gchgjr/switch_sway#c_df7js3

      1. 8

        I can not say enough good about neovim’s design. By taking care of the text editing part, I can focus on the front end concerns such as font selection, glyph calculations, and text rendering. Zero to functioning text editor was really fast as well so it was easy to get started

        I highly recommend making a neovim gui as it gives you a better understanding of how things work in the text editor. @jmk and company have been doing amazing work

      2. 1

        I immediately gave it a shot as I am avidly looking for a nvim GUI interface with good performance and ligature support, but was greeted with a SIGSEGV on OS X 10.15.3. It looks like a know issue, so I’ll keep my eyes peeled.

        1. 1

          Wanna help debug? I don’t have access to a mac and so am kind of at a loss for how to fix this. I think it has something to do with font-kit, but I don’t have any way to know beyond that

      3. 6

        The animated cursor looks like a gimmick, but I have a feeling that it would be really useful.

        1. 6

          It felt like a silly addition to me, and then I realized how often I do jkjkjkjkjk to see where my cursor currently is after searches and jumps. I’m looking forward to trying this.

          1. 5

            It definitely pleases me. Whether it reduces the number of times I lose track of the cursor is hard to tell ¯\_(ツ)_/¯ my impression is yes, but your mileage may vary

            1. 3

              I’ve been using this to help keep track of the cursor:

              set relativenumber
              set number
              highlight LineNr ctermfg=brown
              highlight CursorLineNr ctermfg=yellow
              
              1. 2

                Neat! My vimrc has something in a similar-ish vein with the following line:

                :nnoremap <Leader>s :set cursorline! cursorcolumn!<CR>
                

                Leader s will highlight the current row and current column, creating a “crosshair” over your cursor. I use it all the time when pairing to show someone where my cursor is and as way to “point” at code.

                Plus it’s a toggle. So when I lose my cursor I can just quickly toggle it on and then off with the same binding. Easy for it to become muscle memory.

            2. 3

              Honest question, why would you use a nvim in a GUI which functions like the nvim TUI?

              1. 12

                Reasons I do:

                • Ligature support
                • Animated cursor
                • Faster performance
                • Possibility of future graphical features such as blurred floating windows, frameless window, etc

                Reasons I’ve heard from other users:

                • Identical cross platform experience

                Terminal is great for some things, but these days I use neovim as my terminal emulator, so I guess I’d ask it the other way around. Why use TUI when you can have a terminal inside of neovim?

                1. 0

                  Reasons I do:

                  • Ligature support

                  Notice that many terminals support fonts with ligatures. You can see a handy table of terminals on the FiraCode documentation: https://github.com/tonsky/FiraCode In particular, konsole, qterminal, Windows Terminal, kitty, iTerm, have full ligature support.

                  • Animated cursor

                  What do you mean exactly by that? the blinking of the cursor? I prefer non-blinking cursors but surely all terminals support blinking cursor.

                  • Faster performance

                  I seriously doubt that the terminal inside the editor will be faster than a native terminal. Do you have benchmarks for that? Anyhow, terminal performance is very rarely an issue nowadays.

                  • Possibility of future graphical features such as blurred floating windows, frameless window, etc

                  What are “blurred floating windows” and why would you want such an horrific thing?

                  1. 7
                    • Ligature Support

                    On windows the only terminal that supports ligatures with any semblance of performance is the Windows Terminal which is a new app that has issues of it’s own and doesn’t have mouse pass through at all. Maybe I’ve missed others?

                    • Animated Cursor

                    The gui supports a smear effect on the cursor which helps the user track where the cursor jumps. I find in my usage that I lose track of the cursor in some cases. The readme has a good example of it. This helps with that.

                    • Faster Performance

                    The combination of ligature support and good performance is very difficult to get right. In my experience on windows, terminal emulation is very slow. This isn’t

                    • Blurred Floating Windows

                    Floating windows are a feature inside of Neovim which lets windows appear on top of other windows. Neovim also supports some amount of fake transparency of the background so that characters behind show dimly in the front. This effect is fun and interesting, but a gui should be able to blur the background of these floating windows so that the text is less distracting but the effect is still visible.

                    As mentioned in the other comment, you are being unnecessarily mean.

                    1. 6

                      Your tone is a bit dismissive. You could express your points more kindly.

                      As for performance, terminal latency is still kinda bad for many. See the benchmarks from danluu and others. I don’t think there’s any particular reason to believe that a neovim GUI should have worse performance than a terminal. They do similar jobs.

                      If you look at the readme, you will see what they meant by animated cursor.

                      1. 1

                        Having “full ligature support” on a feature list and actually doing it are very different things. Last I checked (june 2019ish) windows terminal, no Linux terminal i can find, and iterm don’t do ZWJ emoji sequences according to font rules (hacker cat comes to mind but there’s more) or various non-emoji double-width characters right. The only one I know that does (at least as far as my IRC usage and dadaist fish_prompt is concerned) is mintty/putty, and it’s unfortunately slow.

                        1. 1

                          cannot speak about windows, but I’m a happy user of FiraCode on linux terminals (qterminal and kitty), and ligatures have been working since a few years ago (when I first heard about them).

                      2. 1

                        Ligature support and animated cursors are good reasons, but is the GUI faster than e.g. Alacritty, which is GPU accelerated? Also, many terminals can have blurry backgrounds, frameless windows, etc. Identical cross platform experience is also a good reason if it works consistently cross platform.

                        Terminal is great for some things, but these days I use neovim as my terminal emulator, so I guess I’d ask it the other way around. Why use TUI when you can have a terminal inside of neovim

                        I also run terminals inside of Neovim, but it’s far from a tmux replacement. That’s why I use the TUI, to I can use it with tmux.

                        1. 9

                          I don’t know exactly how nvim’s embedding api works, but in principle it should be easier to achieve high performance with a purpose-built editor frontend than a terminal. Reason being that with vt100 all you have is a character buffer, so redrawing only dirty sections requires extra work and increases coupling. But in principle there’s no reason why one would have to perform better than the other, and alacritty has had a lot more work done on it.

                          1. 5

                            Terminals cannot do blurry backgrounds for the floating windows inside of neovim. I think in the end, it comes down to preference. tmux isn’t an option today on windows, so for me the neovim terminal emulation is miles further than anything else I easily have available.

                            Perf wise, its not nearly as good as alacritty yet, but we are working on it, and as mentioned above, alacritty doesn’t support ligatures which is where a lot of the perf cost exists today.

                            1. 3

                              How is tmux not an option on windows? I use tmux in mintty a ton

                              1. 1

                                Gotta use cygwin for that. I’m not a fan, but if you are into that, tmux works great :)

                                1. 1

                                  There’s a WSL port (full disclosure, I haven’t tried it) https://github.com/mintty/wsltty

                              2. 1

                                Fair point, I switched to Linux completely, so I kinda forgot about Windows. But yeah, especially on Windows it’d be nice to have this Neovim GUI.

                          2. 6

                            The terminal literally emulates a decades old hardware design. Using that as a platform is a silly default.

                            1. 1

                              Your cells emulate a billion-year-old hardware design. Please, update to a non-silly platform.

                              1. 12

                                Oh, man. Just tell me how.

                              2. 1

                                The terminal is just too convenient to not use as a platform.

                                1. 6

                                  The concept isn’t the implementation. One can imagine a text oriented user interface without multiple decades of legacy requirements.

                                  1. 1

                                    Hmm, could you expand on how you’d envision that in a bit more detail? Because I’m unsure I completely understand.

                                    1. 3

                                      One could reconsider/omit:

                                      • The entire termcap/terminfo infrastructure.

                                      • The limitation of the vt100 and friends as a medium (strict cell boundaries, no graphics, everything like DBCS/UTF-8 being a graft)

                                      • The raw bytestream nature, using a more structured protocol, which could enable everything from low bandwidth form entry (the 5250/3270 reality) or rich objects in your CLI (think anything from Mathematica to PowerShell)

                                      1. 2

                                        The entire termcap/terminfo infrastructure.

                                        I’m unfamiliar with this infrastructure, what does it do and why is it bad?

                                        The limitation of the vt100 and friends as a medium (strict cell boundaries, no graphics, everything like DBCS/UTF-8 being a graft)

                                        Fair point, having the option to have these things would be a very welcome addition.

                                        The raw bytestream nature, using a more structured protocol, which could enable everything from low bandwidth form entry (the 5250/3270 reality) or rich objects in your CLI (think anything from Mathematica to PowerShell)

                                        Well, if everything would work using that protocol / interface it’d be nice, but raw bytestreams seem to be the ultimate backwards compatible “protocol”, if you could call it such. Having these battle-tested tools which are still usable and easily extensible is quite a boon. The cost of turning over to another system with a more strict protocol doesn’t seem worth the benefits to me personally.

                                        Maybe if there’d be awk-like tools which could parse raw bytestreams to these objects? If this was simple enough, it could provide the same kind of backwards compatibility and extensibility.

                                        1. 5

                                          Well, if everything would work using that protocol / interface it’d be nice, but raw bytestreams seem to be the ultimate backwards compatible “protocol”, if you could call it such.

                                          This is the part of the discussion that really annoys me, because it’s so misleading.

                                          You can just dump arbitrary bytes on a terminal, if you don’t mind it switching into an unpredictable mode, or even crashing. But in reality, there is a protocol made up of the ANSI escape sequences and your codepage (hopefully UTF-8).

                                          Well-designed CLI apps, like vim, will escape these streams just like web apps escape tag characters, for readability purposes, but more importantly to prevent clickjacking.

                                          There are also potential vulnerabilities on the input side, too. For example, what happens if your clipboard contains an ESC and you paste it into vim?

                                          1. 1

                                            I get your point, but that doesn’t take away that its backwards compatibility is unmatched. But rebuilding everything from scratch every x years takes a lot of effort which, most of us, are not willing to put in I reckon.

                                      2. 1
                              3. 1

                                Oh wow. I’ve been primarily using MacVim for a couple years now, and I love it. But this looks like I’m gonna have to give it a shot.