I'll just leave a shameless plug for my neovim GUI project here: https://github.com/vhakulinen/gnvim. It has a WIP PR[1] for implementing multigrid support, which would allow features such as scrollbars.
I just tried this. I get rendering artifacts when scrolling.
BUT! The scroll speed is absolutely wonderful. I've tried all the UIs and always find myself going back to the terminal, but this is something else.
Although I have to say fvim looks tempting as well and vimr(I'm not on MacOS anymore).
For those people mocking vim users and bragging about their IDE's. With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.
The only things that are not really first class citizens are IMHO:
1. refactoring(outside of C++ and Java)
2. profiling
3. breakpoints
EDIT: I'm quite happy with the tmux setup I have but thanks for the suggestions. The main problem I see with neovim is that the separation of the python library while nice for update iterations causes issues with virtual environments.
>Although I have to say fvim looks tempting as well
Visited its page to have a look... I'm not sure why they'd put a screenshot with a variable width font, which automatically puts lots of people off when it comes to coding...
It's like having a screenshot of your bitmap editor, and showing it editing goatse.cx...
I'm not going to mock you, but why not just use an IDE with a vi(m) mode or plugin in the first place, if you really want all those features?
Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.
> With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.
Most likely true, though i think the "I" part of "IDE" is woefully ignored and (at least to me) is much more important than a hodgepodge of barely related programs strung together with duct tape.
If you're using pango 1.44, that is a known issue and there really isn't a proper workaround yet. Quite a few applications using grid based applications are currently broken with pango 1.44.
I am happy with Neovim in a terminal too. But I wanted I wanted it running as a separate application that I could launch and switch to, so I downloaded the iTerm2 source code and changed the icon and application name and created a profile that just runs Neovim. I find this works well, but maybe someone knows a simpler way, or a generic way, to do this on OS X?
I just wish vim+languageserver would catch up to where vim+mlcscope was fifteen years ago. (Specifically, finer-grained distinctions that just references to a symbol, e.g. assignments and calls.)
Both neovim-gtk & gnvim are great but don't integrate nicely with standard ctrl + c, ctrl + v actions which is super frustrating.
VSCode with vim plugin handles this well with the Use Ctrl Keys option set. If you're in insert mode, ctrl + v will paste, otherwise ctrl + v will start visual mode. If you are selecting text, ctrl + c will copy.
Adding a bazillion one-off options like "Use Ctrl Keys" to avoid creating mappings, defeats the purpose of using vim, since creating mappings is the bare minimum way to configure it. (But Vim did so anyways for Windows, in the form of the "mswin.vim" plugin, which is enabled by default, causing confusion for users expecting vim to behave like vim.)
A different way of tackling this if you don’t mind doing it “the vim way”: Most vim builds enable the + register to access the system clipboard (hopefully these two do so too, I haven’t verified!). “+p = ctrl+v, “+y = ctrl+c etc.
If you’re unfamiliar with registers look them up in the docs they are super useful. (Also have a look at the 0 register, e.g. “0p)
In addition to sibling comment - does any vi(m) work with the (non) standard (for vi) ctrl-v/c out of the box? I understand setting the star/plus as default registry so that paste and yank read/fill the system clipboard. But using ctrl-V for paste is surely alien?
Nothing wrong with custom keybindings, obviously. But it sounds rather non-standard?
> multigrid support, which would allow features such as scrollbars
also per-window font-size, dimensions, line-spacing--so Nvim UIs can add unlimited decorations to windows while the editor navigation remains exactly the same (driven by Nvim).
Looks nice, but I'm a bit surprised to see "No web bloat!" and then Webkit in dependencies. Is the UI built in web technologies, just not in Electron this time around?
I don't use vimr that heavily, but a few times now I've seen it chewing on the CPU when I've left it open in the background. I do use neovim heavily and haven't seen that.
I want to take a moment to thank the Neovim authors, as a VIM user. Thanks to you, VIM has felt the pressure and greatly improved, including the vim 8 async plugin feature (which has now trickled-down in all distros).
I can now use coc.nvim and ccls to have an IDE-like experience inside vim, which really helps reducing further the write-compile-test-fix loop.
Never attempted to make the move (friction, sizeable vimrc). I've mostly been using the distro builds, which for neovim often meant an outdated version.
I can also admit that I've benefited from the project, even if I've never used it. Like everyone using Firefox is currently benefiting from WebRender, despite never moving to Servo.
We often find criticisms of forks in OSS (waste of resource, we should work together through a common goal), but the truth is that this flawed mechanism allows for innovation and experimentation. Which is also why the BigCos that ship different competing products (say, messaging apps), are often the most innovative because it prevents (some kind of) in-fighting and cookie licking.
Speaking for myself; vim's always available whereas I have to faff about (especially on older systems, or where I'm not admin) to get neovim working.
The .vimrc files seem to have to live in different places meaning the scripts I've written to install vim/vim-plugins will need to be altered.
Some plugins don't work properly.
I've never got neovim working on windows (can't get the colours quite right)
I tried the built-in terminal and thought it was a great idea but struggled to seamlessly hop between panes, pipe the output into files and open in other windows or copy/paste them. Tmux solves all those problems so I never use the terminal (and if I needed to it's in vim now).
I liked the attitude of the project, but I still have no use for it. One idea which might make sense would be for the vim project to accept the neovim source; merge it back in as vim 9 so all the great refactoring, and other functionality is available for everyone and any wasted effort on two almost-identical projects is avoided.
The most interesting fact about this release - from my personal point of view - is that I don’t care. I am usually very interested in updates to software I use often. nvim/vim is a program I use every day but I never had the feeling that it was lacking anything. I never ran into bugs. I don’t even have the feeling that I will grasp all of its features anyway not to mention the countless plugins. And I expect this upgrade to be stable and frictionless as in recent years. A tremendous achievement compared to all the other programs I have the pleasure to work with.
Somewhat off-topic, but that's how I feel about Sublime Text 3. It's fast. It's snappy. It handles MB-sized files with ease. I use it for text editing, small scripting (shell scripting, JS), repetitive text transformations that can be reduced to a macro, and things of that sort. Anything heavier goes into an IDE.
> nvim_open_win: create floating windows (and external, for supporting UIs)
I've been running 0.4.0 since it came out for this feature.
Also I recommend you check out coc.vim for the best completer. It uses the same language server protocol that VS Code uses (and many of the plugins for coc.vim are forked fr VS Code plugins)
All completers will be able to utilize floating windows immediately, so it's not a special feature of coc.nvim. Using LSP is also not unique to coc.nvim. Deoplete, for instance, supports both as well. I personally have no interest in using coc since it's a javascript based project.
Yes, I wasn't trying to say it's only possible to use with coc.vim, and neither was I trying to say that LSP is unique to coc.vim. But I would not recommend Deoplete.
I have been using LanguageClient-neovim[0]. It is great, the main difference I have observed between LanguageClient-neovim and coc.vim is that LanguageClient-neovim provides a more vim centered UX (e.g. it automatically populates location/quickfix list with errors, warnings and hints which enables quickly jumping between error locations) while coc.vim provides a great out-of-the box experience but feels like VSCode strapped to nvim (It has its own extension ecosystem based on VSCode extensions) - I greatly appreciate the effort by coc.vim's developer, he has done great work and coc.vim defiantly has its advantages[1] over LanguageClient-neovim. LanguageClient-neovim requires a lot of customization in order to fit it to your work flow but once it is done, the experience feels a lot more native. On the topic of which, LanguageClient-neovim feels lighter and faster to me and has the added advantage of being usable without any external dependencies (because it is a compiled binary). I highly recommend checking it out.
tl;dr:
coc.vim is for those looking for a VSCode like experience out of nvim (stuff works out of the box requiring minimal customization, installing plugins to get the required functionality) where LanguageClient-neovim is for those who prefer a vim centric approach (extremely minimal, manually customizing everything to get it to fit you workflow).
If you are interested in LanguageClient-neovim you can checkout my config[2][3] you might find it helpful .
The vim tricks I got used to in the past 15 years are neat for a quick remote edit, however, nowadays I enjoy RAM eating smart editors like vs code and intellij which makes me satisfyingly efficient without remembering to use my shortcuts.
What I do is mostly refactoring, finding files by name or contents and moving cursor to places I've been in which provides seamless navigation between files as well.
It's possible to get a best of both worlds setup if you try. Have you tried the Vim plugin for VS Code?
The VS Code plugin is interesting in context of this Neovim update because it will actually use parts of Neovim as a "native library" to speed some operations (mostly ex commands), if Neovim is installed.
Here's a random question for Vim users who might know Kakoune...
What can be done to make Vim behave like Kakoune? Odd question, I know. As a former Vim user, I switched to Kakoune about a year ago and absolutely love it. The multi cursor behavior, and selection before action combined to make a really excellent and visual experience.
With that said, after 15 years in the Terminal, I tire of it. I want a GUI. Neovim has made some great advancements to getting users out of the Terminal (should they want that), and I envy Neovim users! Yet, I can't get away from Kakoune.
Is there any hope? Appreciate any replies, thank you.
Say you want to replace the contents inside a pair of matching parentheses. Instead of ci( type vi( and if you are happy with the selection, then type c -- that takes an extra keystroke, but gives you visual confirmation of what you are operating on.
Or slightly differently, and this is useful only for "c"hange, add "$" to your cpoptions (that is, :set cpoptions += "$" in your vimrc).
When making a change to one line, don't redisplay the
line, but put a '$' at the end of the changed text.
The changed text will be overwritten when you type the
new text. The line is redisplayed if you type any
command that moves the cursor from the insertion
point.
I don't think the amount of people using any of the various (afaik all rather alpha-stage) GUI frontends is very high at all, at this point.
People use nvim in their terminal, and that will likely be the case for a long time.
In any case, there are many multiple cursor plugs for vim, now also supporting operator pending.
And :substitute includes built-in real-time preview.
So, I used Vim for years - but frankly I only used what I needed. I never played vim-golf extensively, so please don't take what I say as the reasons I enjoy Kakoune as evidence of shortcomings in Vim. With that said:
Kakoune's multi-cursor support sort of blew my mind when I first started using it. Combined with the always selection first model of Kakoune, it means you can plop down 10 cursors, navigate around, select, reduce and etc all of them separately will actively viewing what they have selected. Finally when you get all the selections you want, you can act on them. That's really my main workflow that I just have to have.
Plugins may perhaps solve my issue. We'll see. I also am not sure how realistic living entirely in visual mode in Vim is. I'm not too well versed in visual mode, so I can't speak on it too much.
Kakoune has really been a joy for me. I just want more advanced features that Terminals can't provide (multi fonts, more UI elements, etc)
Last time I checked neovim-qt on mswin, it couldn't make an explorer association due to non-standard command-line treatment, rendering it useless from gui pov. Reporting an issue got some friction, but now it seems that they fixed that. But from double-clicking .txt to editing it spends 2 seconds. Vim just opens instantly.
Also, neovim doesn't respect scroll amount setting, scrolling three fixed lines per scroll step instead. But I have set it to 6.
set guifont=* -- simply doesn't work
set guifont=Consolas:h10 -- "font reports bad fixed pitch metrics". What?
set linespace=3 -- it changes, but doesn't care to redraw contents (except the cursor) or resize a window so it could fit in a screen. If you're going from 0 to 3-4, it is not even obvious why everything froze and you can't : into command mode (it is simply hidden under the bottom of the screen).
I know that they're after fixing some internals that are hard parts in Vim, but if you're replacing a horse with a car, make sure it is more comfortable than a bicycle. I also know that neovim-qt is NOT neovim core, but...?
I really hope at some point we get one official blessed GUI implementation per platform a-la gVim and we don't have to pick and choose which particular one has the least shortcomings.
Readit News
There are many other GUIs too, such as oni/oni2, gonvim, neovim-gtk and neovim-qt. Extensive list can be found here: https://github.com/neovim/neovim/wiki/Related-projects#gui
1: https://github.com/vhakulinen/gnvim/pull/95
BUT! The scroll speed is absolutely wonderful. I've tried all the UIs and always find myself going back to the terminal, but this is something else.
Although I have to say fvim looks tempting as well and vimr(I'm not on MacOS anymore).
For those people mocking vim users and bragging about their IDE's. With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.
The only things that are not really first class citizens are IMHO:
1. refactoring(outside of C++ and Java)
2. profiling
3. breakpoints
EDIT: I'm quite happy with the tmux setup I have but thanks for the suggestions. The main problem I see with neovim is that the separation of the python library while nice for update iterations causes issues with virtual environments.
Visited its page to have a look... I'm not sure why they'd put a screenshot with a variable width font, which automatically puts lots of people off when it comes to coding...
It's like having a screenshot of your bitmap editor, and showing it editing goatse.cx...
Haven't seen this, -it usually goes the other way:
You're doing it wrong, you should use vim!
(I know enough vim to effectively use it to edit configs etc, but I just prefer my IDEs.)
Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.
Most likely true, though i think the "I" part of "IDE" is woefully ignored and (at least to me) is much more important than a hodgepodge of barely related programs strung together with duct tape.
If you're using pango 1.44, that is a known issue and there really isn't a proper workaround yet. Quite a few applications using grid based applications are currently broken with pango 1.44.
VSCode with vim plugin handles this well with the Use Ctrl Keys option set. If you're in insert mode, ctrl + v will paste, otherwise ctrl + v will start visual mode. If you are selecting text, ctrl + c will copy.
Adding a bazillion one-off options like "Use Ctrl Keys" to avoid creating mappings, defeats the purpose of using vim, since creating mappings is the bare minimum way to configure it. (But Vim did so anyways for Windows, in the form of the "mswin.vim" plugin, which is enabled by default, causing confusion for users expecting vim to behave like vim.)
If you’re unfamiliar with registers look them up in the docs they are super useful. (Also have a look at the 0 register, e.g. “0p)
Nothing wrong with custom keybindings, obviously. But it sounds rather non-standard?
imap <C-V> <C-R>+
vmap <C-C> y
Most probably you want this as well:
cmap <C-V> <C-R>+
also per-window font-size, dimensions, line-spacing--so Nvim UIs can add unlimited decorations to windows while the editor navigation remains exactly the same (driven by Nvim).
You didn't even mention it's written in Rust!
Dead Comment
1: https://github.com/qvacua/vimr
Either way, VimR is impressively nice looking. Thanks for the link!
I can now use coc.nvim and ccls to have an IDE-like experience inside vim, which really helps reducing further the write-compile-test-fix loop.
I can also admit that I've benefited from the project, even if I've never used it. Like everyone using Firefox is currently benefiting from WebRender, despite never moving to Servo.
We often find criticisms of forks in OSS (waste of resource, we should work together through a common goal), but the truth is that this flawed mechanism allows for innovation and experimentation. Which is also why the BigCos that ship different competing products (say, messaging apps), are often the most innovative because it prevents (some kind of) in-fighting and cookie licking.
I liked the attitude of the project, but I still have no use for it. One idea which might make sense would be for the vim project to accept the neovim source; merge it back in as vim 9 so all the great refactoring, and other functionality is available for everyone and any wasted effort on two almost-identical projects is avoided.
I've been running 0.4.0 since it came out for this feature.
Also I recommend you check out coc.vim for the best completer. It uses the same language server protocol that VS Code uses (and many of the plugins for coc.vim are forked fr VS Code plugins)
- Are real windows showing real buffers. No shortcuts, hacks, or compromises.
- Can be (re)positioned, anchored, or "external" (if supported by the UI).
- Support all features and API of normal windows, plus more.
Screenshot showing floating window with 'winblend':
https://twitter.com/Neovim/status/1145446583573594112
Yes, that screenshot shows Nvim in a terminal. The 'winblend' feature works in all UIs, including the TUI (all terminals that support RGB colors).
https://mobile.twitter.com/neovim/status/1101893773561348096...
tl;dr:
coc.vim is for those looking for a VSCode like experience out of nvim (stuff works out of the box requiring minimal customization, installing plugins to get the required functionality) where LanguageClient-neovim is for those who prefer a vim centric approach (extremely minimal, manually customizing everything to get it to fit you workflow).
If you are interested in LanguageClient-neovim you can checkout my config[2][3] you might find it helpful .
[0] https://github.com/autozimu/LanguageClient-neovim
[1] It shows documentation for completion list items in a floating window similar to VSCode.
[2] https://github.com/L0stLink/anvil
[3] https://github.com/L0stLink/anvil/blob/master/settings/Langu...
Dead Comment
What I do is mostly refactoring, finding files by name or contents and moving cursor to places I've been in which provides seamless navigation between files as well.
The VS Code plugin is interesting in context of this Neovim update because it will actually use parts of Neovim as a "native library" to speed some operations (mostly ex commands), if Neovim is installed.
https://github.com/VSCodeVim/Vim
Or the worst.
What can be done to make Vim behave like Kakoune? Odd question, I know. As a former Vim user, I switched to Kakoune about a year ago and absolutely love it. The multi cursor behavior, and selection before action combined to make a really excellent and visual experience.
With that said, after 15 years in the Terminal, I tire of it. I want a GUI. Neovim has made some great advancements to getting users out of the Terminal (should they want that), and I envy Neovim users! Yet, I can't get away from Kakoune.
Is there any hope? Appreciate any replies, thank you.
use visual mode more?
Say you want to replace the contents inside a pair of matching parentheses. Instead of ci( type vi( and if you are happy with the selection, then type c -- that takes an extra keystroke, but gives you visual confirmation of what you are operating on.
Or slightly differently, and this is useful only for "c"hange, add "$" to your cpoptions (that is, :set cpoptions += "$" in your vimrc).
In any case, there are many multiple cursor plugs for vim, now also supporting operator pending. And :substitute includes built-in real-time preview.
Kakoune's multi-cursor support sort of blew my mind when I first started using it. Combined with the always selection first model of Kakoune, it means you can plop down 10 cursors, navigate around, select, reduce and etc all of them separately will actively viewing what they have selected. Finally when you get all the selections you want, you can act on them. That's really my main workflow that I just have to have.
Plugins may perhaps solve my issue. We'll see. I also am not sure how realistic living entirely in visual mode in Vim is. I'm not too well versed in visual mode, so I can't speak on it too much.
Kakoune has really been a joy for me. I just want more advanced features that Terminals can't provide (multi fonts, more UI elements, etc)
Also, neovim doesn't respect scroll amount setting, scrolling three fixed lines per scroll step instead. But I have set it to 6.
set guifont=* -- simply doesn't work
set guifont=Consolas:h10 -- "font reports bad fixed pitch metrics". What?
set linespace=3 -- it changes, but doesn't care to redraw contents (except the cursor) or resize a window so it could fit in a screen. If you're going from 0 to 3-4, it is not even obvious why everything froze and you can't : into command mode (it is simply hidden under the bottom of the screen).
I know that they're after fixing some internals that are hard parts in Vim, but if you're replacing a horse with a car, make sure it is more comfortable than a bicycle. I also know that neovim-qt is NOT neovim core, but...?