Neovim v0.4.0
github.com
github.com
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
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...
In fact, after reading you comment, I promptly startet to install it (still compiling as I type this). My use-case is creative writing: I'm very used to vim keybindings from coding, but prefer to have a variable-width fonts for writing.
Sorry about the confusion -- I think you've already discovered that (after 46 minutes)!
Aha, looked like a proportional font was used to me. I'd use a more well designed monospace font for the first impression!
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.
It's not that using an IDE with a vim mode is not a possible viable alternative, but it's a game of trade-offs, as usual.
I really hope in the future I'll find the time to do that, but for now I am content. It's always a trade-off.
Vim also starts up without any noticable delay and can be used for every text file, no matter in what context.
Only if you run it without any plugins. Unfortunately if you have a lot of third party packages, vim startup times start to get closer to emacs startup times (both of which are still better than any IDE I have used, of course). I keep a vim.norc alias in my alias file which launches vim with an empty .vimrc for this very reason.
I’m not very experienced with complex plugins, but most of what I’ve seen did nothing unless explicitly initiated. Maybe there are global variables to control that.
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.
Omnisharp was literally the attempt of MonoDevelop to create an open source alternative to the Resharper engine.
The completion agents for VIM or VSCode do the presentation layer for the lower layer(the language server daemons, or custom completion agents. YouCompleteMe however is all that together in one not as fancy but I like it).
I get where you're coming from, but basically the difference is that vim by itself is a raw editor and until neovim came along never made an effort to merge the functionality that was required for something like this to happen in a nice fashion.
Editors like Oni are basically distributions like VSCode with defaults that are more inline with what you say plus a nicer presentation layer.
Java and NetBeans is (or was, before Oracle botched it) probably the best IDE (in terms of integration) for a toolset with a unixy background.
Though none of those compare to something like Smalltalk, Lisp or even Microsoft's QBasic and (pre-.NET) Visual Basic.
Note that i'm talking about how integrated the IDE is with the language and its tools, not about how good or bad the language is.
Vim didn't allow integration because there was no way interface to it, and it's not an easy codebase. Neovims work is proof of that. C++ compilers didn't allow integration because they were big monstrous projects and when you need to do proper c++ indexing you basically need to compile the whole project.
For C++ this changed with clang and even for clang it took a lot of iterations and bugs inside of libclang to allow for this capability.
Naturally one of the best C++ IDE's was therefore also by the producer of their own compiler (Visual Studio).
These boundaries are slowly fading, so these arguments are kinda moot. A few examples:
https://clang.llvm.org/extra/clangd/
libclang might be a bit closer but it still is something separate from whatever IDE it is used for.
Honestly i do not believe it is even possible to what the sort of integration i'm talking about by stitching together separate projects no matter how many extension points and hooks those projects provide - by definition they aren't made with a singular coherent vision where everything is meant to work together, instead each project has its own idea of how it should work.
MSVC could in theory be able to do that since the IDE is made by the same company as the compiler, but in practice the teams behind it are probably acting as separate "sub-companies" inside the bigger organization. They're not seen as a single "C++ development environment" project but as two separate projects that happen to communicate with each other.
I'm not sure if 'philosophy' is the proper term here, but it is certainly about how you believe that software should be made and having that in mind at all times when designing it at all levels - be it the functionality to provide or how that will be implemented (e.g. a compiler that runs as a simple standalone application can just use globals for the state and perhaps not even free memory at shutdown - see dlang as an example - whereas a compiler meant to be integrated as a library cannot do that).
As an example, for a Borland-like approach (at least based on my understanding of it), adding a language extension to -say- provide meta-data for classes wouldn't be something that only the compiler developers cared about, but something that the developers of the compiler, the debugger (for being able to display the meta-data), the IDE (for editor auto-completion and automatic code editing - later Borland IDEs could modify the code - and debugger UI), the framework library (for taking advantage of it and providing a 'best use' scenario), etc. And all of those would influence the new functionality instead of being something that was added by the compiler team and then the rest would have to support (as it is done by pretty much every language that only exists as a standalone compiler or interpreter without any concern for IDEs, debuggers, UIs, etc nowadays).
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.)
inoremap <C-V> <C-R>+
vnoremap <C-C> "+y
cnoremap <C-V> <C-R>+ vnoremap <C-X> "+ygvdIf 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>+
The C-v (Ctrl+lowercase v) is important for literal character insertion. (Insert a tab, escape, return, etc.)
You can remap it to <C-l> (L = literal), and then use <C-c> and <C-v> without shift:
inoremap <C-l> <C-v>
imap <C-v> <C-r>+
cmap <C-v> <C-r>+
xmap <C-c> "+yTIL. This goes into my vimrc right now.
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!
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).
> slightly concerned that neovim started to cut bloat in vim and ended up implementing a compositing window manager with fake transparency.
"Window manager" existed since vim got split-windows (1990s). Redesigning it as a compositor:
- isolates windows logically, so that UIs can do their own layout instead of being stuck with the TUI grid
- useful for implementing floating windows
- allows reasoning about layers instead of one grid driven by special-cases throughout the project
- helps with features such as "click through", z-index, etc.
The blending (fake transparency) was a small (~200 LoC) amount of code, added only for fun (and to ruffle feathers).
Thanks for all the work Neovim team!
I do recognize that I prefer software to be simpler than most people (for the record, much of the time I use ed(1)).
Though the idea is just pretty damn cool in general so I can't get too grumpy about it.
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...
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.
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).
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.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...?
https://github.com/neovim/neovim/tree/master/.builds
Welcome to the platform!
The other big win is providing a embedding API so other editors can be built on top of the core editing engine. Which resulted in multiple interesting GUI projects which you can find in other comments.
Others are Lua plugin support, good terminal integration, way better default settings, ...
That's more to do with how you setup to trigger the commands.
Async here really means that it doesn't block with your typing, jumping around in the text editor if plugin starts doing some heavy work in the background due to some action that got triggered by whatever event you had setup for plugin to do. One of the plugin that I particularly remember was syntastic (I haven't kept up with it to know if they've fixed this or not) that would just create janks every now and then if the workload was heavy.
1) In visual mode you have a block cursor and in insert mode it is a |.
2) With ':set inccommand=nosplit' you get live previews for substitution calls. For example :%s/foo/bar/ will update your foos on screen whilst you type the command.
Otherwise it is pretty much a drop-in replacement without issues.
Except for the crashes. The crashes are an issue.
Don't get me wrong though, I like nvim. I use it occasionally.
But the crashes are an issue.
They only real negative in my view is the startup time which is noticeably worse than vim for me. Advantages I see are
- unix clipboard and middle mouse pasteboard both work out of the box without having to recompile (ie "*p and "+p and the corresponding yanks just work) whereas on vim for whatever reason I always have to rebuild my distro vim and faff about with terminals for ages
- the substitution preview thing above is really great
- the "terminal" window type which I don't use much but a lot of people do
- the fact you have native support for python3 and python2 plugins simultaneously. Don't even want to think about how many goats had to be sacrificed to build that feature but it's cool
- the ":checkhealth" diagnostic screen that gives you useful info to allow you to easily fix any problems you're having with terminal and plugin setup
Check that this is not e.g. due to Python host detection/setup - you might have plugins that trigger both py2/py3 hosts to load for example. (hosts can be configured explicitly to skip it) Also check `nvim --startuptime /tmp/nvimlog`.
I've aliased vim to neovim a few years ago and it has not crashed once for me.
I generally start vim in my src folder on Monday and exit it on Friday. Occasionally, just on a whim, I run nvim instead. Mostly its fine. But the times I've experienced crashes or other hickups like rendering bugs forcing me to :qa!, it's been on nvim.
Edit: Oh and I run it in the terminal, iTerm2 to be precise.
——
(* IM could be discord, gitter, slack, or whatever.
I’d argue strongly against IRC because I think the lack of support for code blocks and especially newlines makes it harder to talk about code/stacktraces.)
I used ALE and Deoplete + a bit of Jedi and got frustrated with it breaking / working much worse than ST3 and just removed all the plugins.
Status bar is lightline[2] with a custom theme, which I haven't gotten around to pushing yet. I can share it if you are interested. Other than the colors on the bar everything should work.
[0] https://github.com/autozimu/LanguageClient-neovim
Lets say I want to create a "floating" window on the side and populate it with some text. Where do I start?
best place would be the docs :h nvim_open_win()
here is a function that takes a buffer id and creates a floating window based on it anchored to current cursor position:
let s:buff = 0
let s:buff_max_heigth = 12
function! CreateTempBuffer(buffer) abort
let text = nvim_buf_get_lines(a:buffer, 0, -1, v:true)
if s:buff == 0
let s:buff = nvim_create_buf(v:false, v:true)
endif
call nvim_buf_set_lines(s:buff, 0, -1, v:true, text)
let height = len(text)
if height > s:buff_max_heigth
let height = s:buff_max_heigth
endif
let width = 0
for index in range(len(text))
let line = text[index]
let lwd = strdisplaywidth(line)
if lwd > width
let width = lwd
endif
let text[index] = line
endfor
let width = width + 1
let opts = {'relative': 'cursor', 'width': width, 'height': height, 'col': 0,
\ 'row': 0, 'anchor': 'SW', 'style': 'minimal'}
let win = nvim_open_win(s:buff, v:false, opts)
return win
endfunctionIs there no corresponding `nvim_copy`?
If you prefer a keyboard driven workflow learning to use a terminal and terminal based editor will give you a very portable solution.
Vi's commands are somewhat like a language for manipulating text. This is a different philosophy to many non-modal editors. In vi you can say change the next 3 paragraphs to foo or replace the text inside the this tag with bar. When you learn the language it's almost painful to watch someone trying to select text with a mouse. (I realise GUI tools often have vi plugins. I think that only proves that modal editing is useful and ergonomic once you've learnt how to use it).
CLI based tools are also very scriptable where that is often not the case for GUI based tools. Vi/Vim/NVim are part of a wider ecosystem of tools. If you learn the Ex commands for things like substitute/replace in Vim you're taking a step along the road of learning sed also.
You mention a lot of scripting, and also the terminal.
Would you also recommend vim for working on large projects with 100+ files? I believe in this case, a full on IDE is suited better.
Also I'm not so sure about the portability. Sure, some of the knowledge is reusable, but when all the vim installations are not "batteries included", every installation will be configured differently.
Another point: I think with strongly and statically typed languages one shouldn't think about writing code as writing text, but about building a syntax tree that happens to be text.
You would be surprised by what Vim can do out of the box simply by turning features on. It's also very easy to move configs about. I use github for that job but I can use Vi/Vim without a config if needed.
However what I really mean by portability is that once set up I have exactly the same shortcuts on both my own mac, client's linux laptop and servers. Currently I use tmux for window management but I could use NeoVim for that now. If I want to open a split terminal window or move an existing one about it's exactly the same short cut on each machine.
> Another point: I think with strongly and statically typed languages one shouldn't think about writing code as writing text, but about building a syntax tree that happens to be text.
That's in no way tied to a GUI and there's nothing to stop you adding IDE like features to an editor like Vim. The terminal is just another way of representing tooling to the user.
However if you prefer a GUI interface then nothing stops you from using that in preference to the terminal either. I only point this out as the grand parent asked why we would bother in 2019.
I do that now.
IMO, it depends on the language. For C#, nothing beats Visual Studio. For all of its warts, the autocomplete, go-to-def, and debugging just work too well. I do use a Vim plugin in it. It's missing some features that full Vim has, but the other advantages make up for it.
For Ruby, Python, etc, I think pure Vim wins, including with large projects. I know it's possible to get autocomplete support in Vim, but never found it to be worth the trouble for those languages. No issue in handling a bunch of files with Nerdtree and CtrlP. I think the terminal is better for actually running the program and related tasks than any IDE environment I've tried. Especially with Tmux to spin up new windows easily and switch between them, all without ever leaving the keyboard.
It is true that vim installs tend to be highly configured. IME, the bone-stock Vim on servers is easy enough to live with for the purpose of editing a couple of config files. Wouldn't be thrilled to use it on a large project though.
I'm saying that as an emacs user. I prefer emacs, but if I had to work with a language (e.g. Java) where language support is much more sophisticated in a tool like, for example, IntelliJ, then I'd use that instead, because it would make me much more productive.
First of all, I don't know about vim/neovim, but I think a lot of the issues apply there as well.
When I develop software, I don't need an editor, I need a development environment. I spend 90% of my time reading code, so reading and navigating the codebase should be very straightforward. Most importantly I want to have a tree view of the files in the project, I want to be able to jump to function/class definitions and I want to show usages of functions.
Another big thing is debugging. IntelliJ has really good debugging capabilities.
Also auto-completion.
I think some of these you can get in vim/emacs, but it doesn't come out of the box. I sometimes miss some of my emacs shortcuts/features, but not enough to drop all the amazing things that IntelliJ is offering.
For navigating the project I use helm on emacs, fzf on vim. I can just fuzzy-match anything I'm looking for instantly. I find filesystem treeviews useless, they use a lot of screen real estate and they're annoying to navigate, I don't see the point.
For navigation ripgrep does most of the job complex language engines do and it works across languages without any configuration. For C I sometimes use cscope and ctags but even there I often just call ripgrep because why not?
For auto-completion I also find that a very naive algorithm completing words from existing buffers works reliably and efficiently, with zero configuration and tweaking. Sure you don't get context-aware completion but that never bothered me too much to be honest.
For debugging I can't really disagree with you, both Vim and Emacs are very limited in that regard (Vim especially so).
That being said, maybe if I gave those big IDEs a chance I'd never go back, who knows. Besides I could spend an hour listing things I think Vim and Emacs do wrong so it's not like I think they're perfect editors.
Debugging, while perfectly doable depending on language, is I'd say the one thing still rather awkward.
That is a great point, and this is precisely the goal of the Language Server Protocol[0] (LSP). I agree that dedicated tools have more sophisticated support but LSP is quickly bridging that gap. With how extensible editors like vim and emacs are coupled with there powerful text manipulation capabilities the development experience offered by them in combination with a good Language Server and Client is not to be underestimated. Although editor ergonomics are very subjective so I know this topic can get very controversial.
Language support tools are not dependant on running GUI based IDEs any more.
Hopefully other projects such SpaceVim or individual plugins can provide an easier path for those that want it. I think it's on NeoVim's own road map to add LSP support out of the box.
Of course it's also worth pointing out that whilst it's nice that NeoVim is learning new tricks nothing about having better CLI based tools available means that you can't still use GUI based IDEs if that suits your use case better.
Chances are the Emacs-users are working on files on that server remotely via TRAMP, from their nicely and 100% personally customized Emacs-installation.
Why bother replicating all that setup on a server when you don't have to?
Non-inclusive-we 'need' it because we want it and will make it ourselves. Inclusive-we do not because your individual needs were never and should never be the concern of a project that you have no investment in.
There are lots of other stupid things about it too.
I love it dearly, but English is not elegant or concise.
With a fuzzy finder, Neovim start up in milliseconds and can scale to projects with several thousand files, complete with documentation, symbols, reference jumping, and refactoring. An IDE just turns my laptop into a space heater with minimal configurability and fewer features. In other words, I am investing more battery life for a weaker program. If I need to use someone else's computer (or a container), I can run Vim with my config file right in the terminal and never notice the difference.
The features I need:
1. FOSS
2. A reasonable amount of battery, CPU, and memory usage. The editor should not bring a browser/JVM with it. Browsers eat RAM and need to be restarted within a couple days of uptime, and the JVM kills the battery.
3. Cross-platform; should work on Linux and BSD.
4. Should scale to large projects with thousands of files.
5. Should support advanced features with something like the Language Server Protocol.
6. Minimal UI and keyboard-driven; screen space is often limited, and I hate the mouse with a passion.
Vim and Emacs are the only editors I have ever used that have all of the above features. Nothing else comes close.
Learning neo/vim has been interesting in many regards. I now have a more "portable" setup (up to plug-ins)