What is Reddit's opinion of Neovim?

vim is like the universal text editor for

programming laguages
config filles
anything with formal sytax
anything with balanced braces

It can handle everything pretty good. However, it is not an expert in any single file type. vim really shines when you edit whatever.py and then stuff.go and then reddit_bot.cpp and then video.ini and then fix_flicker.patch before tweaking your systemd.conf and comparing your nginx.conf to animal_list.json.

It is very different from what is a regular text editor nowadays and you will learn a lot basic editing up front before it becomes useful.

There is a lot of stuff in vim for historical reasons and a lot of plugins that can add language specific features. I recommend visiting https://neovim.io/ if you want to start using vim.

I think that you are pretty far off base claiming that the "NeoVim people" (whatever that even means) claim that Vim is "horrible and unusable", given that the entire premise of the project is to maintain parity with Vim. And as for your other claims, just a quick browse through this sub indicates that people are hardly "coming out of the woodwork to yell" about things. As for the business with Bram, while I can't speak to the technical side of things, I suspect that you are in the extreme minority if you don't think that his management style is lousy.

The main thing I've used is the built in terminal, it's nice to not have to run tmux or use panes in a terminal emulator. I keep all of vim's regular keybindings. The other main feature is the async api. While vim also has an implementation I've heard it's not as nice to use and some plugins only support neovim's api.

Finally remote plugins which you can learn about here.

For me the main reason was why not? It doesn't break compatibility with vim, has some nice features and the attitude of the developer toward contributors seems better (from what I've heard).

Edit: Also this

One of Neovim's banner features is that it has full terminal emulation baked in. It is invoked with the :te[rminal]command. It is worth reading the helpdoc on this, as it is pretty versatile. So far as I understand, this should do everything and more that you would do with :shell in mainline vim.

*edit: I would also add that if you plan to explore (or use) Neovim at any length, it will be worth your time to browse through the :help vim-differences portion of the helpdocs (also available online here).

This is going to be a Neovim tip.

Neovim has some saner defaults than Vim. If you migrated your Vim .vimrc to a Neovim init.vim you might have redundant settings lingering.

From the Neovim documentation:

- 'autoindent' is set by default - 'autoread' is set by default - 'backspace' defaults to "indent,eol,start" - 'complete' doesn't include "i" - 'display' defaults to "lastline" - 'encoding' defaults to "utf-8" - 'formatoptions' defaults to "tcqj" - 'history' defaults to 10000 (the maximum) - 'hlsearch' is set by default - 'incsearch' is set by default - 'langnoremap' is set by default - 'laststatus' defaults to 2 (statusline is always shown) - 'listchars' defaults to "tab:> ,trail:-,nbsp:+" - 'mouse' defaults to "a" - 'nocompatible' is always set - 'nrformats' defaults to "bin,hex" - 'sessionoptions' doesn't include "options" - 'smarttab' is set by default - 'tabpagemax' defaults to 50 - 'tags' defaults to "./tags;,tags" - 'ttyfast' is always set - 'viminfo' includes "!" - 'wildmenu' is set by default

I often see a bunch of these redundant settings in people's init.vim when browsing dotfiles on GitHub.

See this talk by u/justinmk here. It explains why they're not deprecating anything just yet.

To summarize, old code isn't bad code. It's code that worked at one point, and is therefore valuable. Granted, old code isn't necessarily designed the best way possible, so we need to move away from it in some cases, but you should generally try to modernize what already exists instead of reinventing the wheel.

That's what Neovim did; it claims to have the most advanced VimScript engine in the world, featuring an AST-producing parser.

Neovim's goal isn't to deprecate old interfaces, which necessitates a trade-off between forward-progress and backward-compatibility. The goal is to modernize the existing codebase, i.e. with libraries like libuv, and make it possible to have more features.

From Neovim's official roadmap:

Lua remote plugin host
Lua user-config: init.lua
Treesitter syntax engine
LSP client for code navigation, refactoring
Extended marks (text properties, decorations, virtual text)

Edit: format.

Embedding neovim should be possible by binding libnvim's C API, or maybe by using its MessagePack-RPC.

There are no MessagePack implementations in eLisp, to my knowledge, so going the latter route seems impossible at present.

Even if you got neovim embedded in Emacs, I wonder how integrated the two would be. Would you just wind up with a separate app acessible from Emacs (kind of like libvterm), or could a tighter integration (more like eShell) be possible?

The advantage of evil is that it's all in eLisp, so how it works is completely transparent and Emacs-native, if you will. While with libnvim, one could go as far as the bound C API functions and no further (without diving in to C, anyway).

It would be interesting to see how neovim embedded in Emacs would work in practice, however.

Also, I'm interested in what you miss from vim. For me, the main things are its regex syntax (which is more powerful than Emacs' regexes in some ways), and vim's much better performance on large files. Other than that, I really can't think of anything.

Neovim is also worth mentioning. The difference being that it's intended to be a drop-in replacement, so the improvements are more in implementation architecture than user-facing behaviour. It's still probably nicer to use than vim because of these improvements, e.g. I believe vim is mostly single threaded, so can block on a single plugin, while nvim will not

Keep an eye on https://neovim.io/roadmap/ which has links to the milestones. We are focusing on 0.1 and there aren't any major blockers left, just a few bugs.

0.1 will support linux/bsd/osx, but not Windows. In 0.2 we will focus on shipping a GUI and finishing up the Windows support.

Nvim documentation: vim_diff

Vim users who haven't migrated to Neovim, why?

Strictly speaking, this isn't fully true. Neovim has no idea what is on the other end of the communication, the only real condition is that it speaks msgpack, which most languages do. Python remote plugins don't ceccessarily NEED the neovim module, it's just that they all do, because the programmer chose to use it.

What the module provides is a plugin host, which provides quite a bit of ease for the programmer. And that is what the python neovim module provides. If you write a python plugin, and are willing to deal with all the nitty gritty communication details yourself, you can do it without the host, and the users won't need to install the module then.

You can read more about all that in the documentation.

As an example, I'm writing a rust plugin, and there's no such thing as a rust host. I'm using a helper library, that does all the heavy work, but in the end my plugin is just a binary, nothing else, and of course neovim has no idea what it was written in.

Check out their homepage if you want to see their selling points that would/are persuading users to give it a shot.

Not only is it a cleaner codebase, but it's a 30% smaller one.

Ergonomic peripherals, and do a whole bunch of short usage periods instead of one really long period (the pomodoro technique and its breaks are good for this).

The biggest is avoid a mouse whenever possible (and use home row keybindings to minimize wrist and finger movement). With video editing it's hard to do; but for programming almost my entire computer is keyboard-based—vim, tiling WM, qutebrowser, TUI applications—and I guarantee you it's the only reason I don't have arms as fucked up as Adam's are right now. If you need to use a mouse, video editing for instance, then a trackball and/or vertical mouse are the best bet.

I believe you don't need to specifically enable the first two in Neovim, since they are enabled by default.

For shortmess, if you are using the latest Neovim master, you can use vim.opt.shortmess:append("c"). As far as I know, there wasn't an equivalent to += before.

The main differences between vim and neovim can be found here.

With the plugins I use, there's really no reason I couldn't just use vim now that nvim-completion-manager and ale both work on vim8.

That being said, neovim has the inccommand option which is simply awesome. It will show you substitutions in real time in the buffer as you're typing out your regex. I only learned about this feature the other day, but it's incredibly useful.

Those are provided by https://github.com/rcarriga/nvim-notify

LspUpdate simply dispatches notifications via vim.notify the rest it's up to end users (you can use a plugin like that or any other notification plugin, or no plugin at all, etc.).

I predict this thread will be full of people conflating "ex mode" with "ex commands".

Nvim 0.3.1 simplified some things related to ex mode, in particular Q is equivalent to gQ.

> Also, do you recommend learning about ex mode?

There's not much to learn. Ex mode is useful if you have a newline-delimited script that you want to pipe to N/Vim, via stdin:

cat script.vim | nvim -es

Ex mode is also useful if you want to run N/Vim as a silent "batch" script engine, i.e. without a UI. But the help in Vim makes this very confusing. Nvim 0.3.1 simplifies the related help and added some new tags:

:help -es

:help nvim-features is a more up-to-date and complete reference, that Progress page will be removed soon. The "single source of truth" is intended to be :help nvim-features.

Oh hey, I just got this working today!

I'm using neomake, which is a plugin that works for regular vim, but really shines when used with neovim. It can be set up to run a parse-only rustc invocation (which finds grammar errors), as well as a full-on cargo build, piping errors into the vim buffer.

I go with the full cargo build, and because I'm using neovim, I can keep typing while the compile is happening and it'll get updated asynchronously.

Here's a screenshot of it in action.

And my configuration (first 2 lines are personal preference)

let g:neomake_echo_current_error=1 let g:neomake_verbose=0 autocmd! BufWritePost *.rs NeomakeProject cargo

Pip doesn't install neovim, unfortunaltely. Installation of nvim is done via your OS package manager.

You just need to follow the official guide posted on their website: https://neovim.io/ which will take you to their wiki page detailing out on how to install for each OS.

Help pages for:

<code>'formatprg'</code> in options.txt

From my perspective, there is no reason to switch to Neovim.

You can read Nvim documentation: vim_diff to check the changes made in Neovim compared with Vim.

Neovim introduced terminal buffer first, but Vim implemented it better.

Just in case it floats your boat, neovim offers an RPC API via msgpack, so you can basically write plugins in any language you like, as long as it offers msgpack functionality. This of course includes clojure. There is a clojure client library and a template for it. While I can't vouch for the quality of those, getting started might be easy :)

Well, I can only offer my perspective so it may or may not reflect the opinions of others. Two major turn-offs of Sublime:

It's not open source
You can only extend it with Python

First point is major for many reasons. One of them being not being able to change the second problem (or various other smaller issues). I myself refuse to build my workflow on top of something that is solely controlled by someone else. Even if large enough portion of the users would want to there can't be NeoVim of Sublime.

Glad to hear the pre-built package was useful.

> maybe stuff like this needs to be emphasized as well,

It was mentioned in the newsletter, on twitter, in the help docs, and in the FAQ. What do you suggest to make things more clear (genuine question)?

>why is my Neovim still at version 0.4 not 0.5?

https://neovim.io/

>FAQ
>What is the project status? > The current stable release version is 0.4.4 (RSS). See the roadmap for progress and plans.

> Regarding WFH, Neovim might be some of the core developers main income? > https://neovim.io/sponsors/

No. That is used to fund selected developers whenever someone has 1+ months to work full-time on the project. It funded the LSP work in winter 2019, and now there's enough in the fund for another project.

FWIW, until now 7 different developers have been funded. $2500/month (before taxes) is not enough to fund anyone permanently, though we recognize and appreciate that this is still far more than many OSS projects receive, and are grateful for this level of support.

Some notable outcomes of funded work include:

LSP integration
job-control and :terminal
VimL expression parser
'inccommand' (partially)
Critical bug-fixes and improvements to the test infrastructure and job-control subsystem

VimR (https://github.com/qvacua/vimr) is more of a wrapper than an integration, but I'm not sure I understand your exact question, so maybe that's what you're looking for? In my experience, VimR works well. It renders as fast or faster than any terminal I've used and via the built-in Neovim terminal, can be a pretty good stand-in for a terminal-ish experience. It has had intermittent stability issues for me. That said, it's being actively developed and I haven't used it very recently - perhaps it's more stable now.

The Neovim roadmap lists "Embed Neovim everywhere" under "Future/Long-term" so I wouldn't expect the developers to be focused on enabling full integration any time soon.

if youre referring to the fact that different distro's change vim feature at compile time, leading to different feature sets (and sometimes multiple packages like vim andvim-huge), then no. website source.

Neovim has more sensible default settings, which are in almost every vimrc out there. Also, when it was first released (so before vim 8), it supported async plugins, which was a big missing thing on vim.

If you want more info on what neovim brings, go look at the help page

You might want to check out neovim's inccomand option in that case :) See here for a little demonstration (as an option, you can have a split window, showing the matches and the replacements).

If you look a little to the right on the shop page, you see: The Neovim logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. That is confirmed by the neovim.org page.

You can get the logo here: https://neovim.io/logos/neovim-logos.zip

> allowing you to mix old viml functions with new ones

Well I'm sure that has no maintenance headaches or negative impacts on Vim9's spec...

> Fortunately, neovim can also run old viml functions

Yeah, it was more around whether the JIT would make all viml faster, than compat. It would be pretty funny if nvim was just "viml but 10x faster".

e: interestingly, nvim wrote a viml parser that returns a proper AST https://neovim.io/doc/user/api.html#nvim_parse_expression()

VimL will forever be supported, at least according to the about page:

Goal: Develop first-class Lua/LuaJIT scripting alternative to VimL.

Non-goal: Deprecate VimL

https://neovim.io/charter/

Huh, seems this test uses cwh instead of pvh. I wonder why that is, I kinda remember that differently. Also, I'm wondering where that is documented. The inccomand option mentions a preview window, which kinda implies pvh for me. Might be worth raising an issue, or asking on gitter or something.

Yes and no. Yes, because all vim plugins (not using vim9 second generation VimL langauge; I am not sure how really popular that is) are also neovim plugins. No, because the support of Lua in vim is not 100% same as the one in Neovim, so Lua plugins written for Neovim most likely (not necessarily) won’t work.

Help pages for:

<code>vim-differences</code> in vim_diff.txt

Help pages for:

<code>conceal</code> in syntax.txt

Help pages for:

<code>'statusline'</code> in options.txt

Help pages for:

<code>autoload</code> in eval.txt

Help pages for:

<code>'formatprg'</code> in options.txt

Help pages for:

<code>undo_ftplugin</code> in usr_41.txt

I haven’t used Vim for a while, switched to NeoVim not long after it was released.

The overarching differences are it’s community built and progressive while retaining all that Vim goodness.

Initial killer features for me were things like async, language providers, and massive potential for extensibility. Personally prefer tmux to the built in terminal.

Today, Lua’s being adopted, LSP built-in or VSC via coc.nvim (atm you’ll probably prefer the latter for those languages), treesitter has a lot of potential, etc.

If you really want to get into it, checkout the releases page and roadmap.

I was asking a legitimate question. Sure COVID-19 might be the reason, hence my question.
There are also other core developers that have contributed much less the last year+. u/mhinz. u/ZyX-I (hope he is OK?)
Regarding WFH, Neovim might be some of the core developers main income? https://neovim.io/sponsors/

FAQ

How can I sponsor Neovim?

Neovim operates a Bountysource campaign to fund ongoing development. This makes it possible for core developers to work full-time for a month or longer, accelerating projects like Lua integration, the VimL engine, extended marks, embedded terminal, job control, and the RPC API.

They have similar features so far, since both projects are fueling each other’s innovation, but I think neovim would leave vim in the dust once they release their LSP implementation.

I personally use neovim, but you can check both projects simultaneously if want using the same vimrc via this method: https://neovim.io/doc/user/nvim.html#nvim-from-vim

I personally use neovim since plugins are much richer and have better support, for example, fzf first popup window preview implementation came from neovim. Last time I checked they were still discussing wih bram on how to support TUIs in vim’s floating window implementation.

Help pages for:

<code>'keywordprg'</code> in options.txt

^`:(h|help) <query>` | ^(about) ^(|) ^(mistake?)

Help pages for:

<code>vim.lsp.buf.document_symbol()</code> in lsp.txt

^`:(h|help) <query>` | ^(about) ^(|) ^(mistake?)

> My friends cringe (or wonder) when I start doing stuff with Vim but, I can't convince them how pleasing and easier it is to get things done on CLI.

For Vim, you can show them GUI text editor which is called, Oni. It is using neovim as backend, so you can enjoy your vim bindings and of course plugins by just editing ~/.config/nvim/init.vim.

The thing is nobody really uses it anymore, and it's really just included for the sake of backwards compatibility. But it is interesting that we still have a piece of software that was originally developed on a PDP-7 that's still available, just in case anyone still needs it for some reason.

On the other hand, one of its descendants, vi, is still pretty commonly used in limited environments, even though that came out in the 70s, too, though it's usually just symlinked on most systems to the newer improved vim which was first released in 1991. It still receives updates today, but it has to maintain backwards compatibility, which is why the project Neovim is being developed. Personally, I'm sticking with vim for now, since there's an ocean of documentation and scripts built around it, and nvim's still in its infancy.

Basically, the UNIX community had already gone through a couple generations of text editor before DOS was even on the scene, and they're still usable today if you really want to try them.

This is trivial in Neovim, using the winhl feature.

The NormalNC highlight group can also be used to highlight the "non-current" window differently. Example:

set winhighlight=Normal:MyNormal,NormalNC:MyNormalNC

For your case where you want it to be filetype-specific, you could do something like:

hi NormalPy ctermbg=red guibg=red hi NormalJS ctermbg=green guibg=green au BufEnter * if &ft='javascript'|setlocal winhighlight=Normal:NormalJS|endif au BufEnter * if &ft='python'|setlocal winhighlight=Normal:NormalPy|endif

Ahh I see. Thanks! I do see that the Neovim Roadmap has a longterm goal of creating a syntax API. That could be awesome. I'm imagining an asynchronous external process that robustly determines the syntax highlighting. Even if the external process is slow (for the sake of accuracy), it wouldn't be that big of a deal since it would be async!

Asking on reddit is a good first step, especially for usage questions like this one. If it's a real issue, vim/neovim have issue trackers that you should put an issue on, but investigating first is always a good thing. If you want different channels to ask at, have a look at https://neovim.io/community/.

Philosophically Neovim does not exist to be a simple fork of Vim as you appear to want it to be. This charter may help explain:

> Neovim is a refactor, and sometimes redactor, in the tradition of Vim.

Emphasis on redactor. As one of its goals Neovim core aims to be a component that may be embedded elsewhere. Neovim clients for Windows will come (including VSCode + Neovim); till then you have gVim. Heck, you may never have need to move to Neovim (unless you need a Neovim only plugin) since Vim actually is perfectly fine for most use cases.

All I ask is that you understand that the Neovim team's goals are simply not the same as yours.

Here is the Neovim roadmap if interested.

The <code>gf</code> command works in terminal buffers. If you run a command in the shell that outputs filepaths, you can position your cursor on that filepath and press gf to open it in the current nvim instance. That replaces the terminal buffer in the current window with the buffer containing the file, so it's not exactly what you asked for, but you might be able to use that as a starting point.

hmmmmmm

Neovim Logo	Nougat Logo
https://neovim.io/images/[email protected]	https://2.bp.blogspot.com/-pCKwhU5NPgs/WDRxwRl5qlI/AAAAAAAADio/e0wpni0r28A8ochP1pwbd38rKo_v3HvmACLcB/s200/image01.png

Use Neovim. With Neovim, scripting languages plugins support is done externally(via msgpack API) so it doesn't have to be precompiled - you just need to install the Python support package.

https://packages.debian.org/search?keywords=neovim

I can't help you with that, just tell you the following: At least justinmk reads this subreddit, he might be able to help. Otherwise, joining the neovim gitter (see https://neovim.io/community/) would likely be a good idea, most of the competent people are there.

Is neovim stable or does it break from time to time? ~~Do I need to change stuff in my vimrc to switch or is it backwards compatible?~~

EDIT: I'm an idiot, ignore my second question :) https://neovim.io/doc/user/nvim_from_vim.html

I'm starting to play with spacemacs it looks really promising, and it often feels like the best of two worlds to work with. neovim also is very interesting. But then again, so much work already went into org-mode, so why not use it was what I was thinking.

NeoVim has C-S support since April if that is something that may interest you. https://neovim.io/news/2015/april/

I'm keeping an eye on the project and am willing to support them financially. However, there's a long road still until it's stable. Also, one of the biggest factors for using Vim is that it's ubiquitous. Most *nix terminals you connect to will have it available, and the few that don't, will in all likelihood have vanilla-'vi'. vi being a huge pain in the ass to use, but at least it feels familiar to Vim minus some nice features.

mind you, i'm not replying to argue against your point, just to provide further information for OP or anyone reading. not that i would speak out of term, but obviously, with my aforementioned vi* "tenure", i won't pretend to know the differences between vi, vim, and neovim. i would, however, feel comfortable assuming the core commands are all the same, as far as "text editing" goes. vi is available on most distributions as part of the core, yes, i believe that is true. if vim gets installed, with the exception of the root user, i would go as far as to suspect that most distributions would find a way to link /usr/bin/vi to /usr/bin/vim, so users would actually default to using vim, anyways.

either way, i firmly believe that one shouldn't limit themselves, especially in the year 2021, to ancient software. vi should be for bare bones dire situations, especially if alternatives are available which, at their core, function more or less identically. regarding neovim, it's certainly different than vim, but once again, the core functionality is the same. it will edit text files just like vi, if that's the task at hand. just my thoughts on the matter, as someone who, in hindsight, regrets making pico and then nano the first thing installed on every new system for a couple of decades.

also, for reference, here is some documentation from neovim on the main differences between it's self and vim. -- https://neovim.io/doc/user/vim_diff.html

as a 20+ year nano user who only knew :wq!, i wish i would have not been "scared" of vi for all the years i was.

if OP is serious about getting into nix then they should go ahead and learn vim. *(personally, i use neovim.) specifics aside, it's very powerful and has certainly been a game changer. i haven't learned near enough about it, yet, and still use the regular arrow keys for navigation, but i can honestly say it's not as hard or confusing as it seems like it would be to learn and use.

Vim and neovim are not identical. Pretty much most things after the fork behave differently, and scripts making use of v im8 functionality will likely not work in neovim. Neovim even has a help page outlining all the differences: https://neovim.io/doc/user/vim_diff.html. Vim 9 script will also not work.

If you read that list, the differences, while in many cases subtle, are extensive. You cannot readily assume that a script written for vim will work properly in neovim.

You shouldn't really need a specialised/dedicated WM I don't think. Neovim's API offers sophisticated controls for GUI clients (for example) to create/manipulate native windows.

I think the main thing now is probably waiting for one of the nvim GUIs to develop the appropriate features. Goneovim looks like it's getting there and may already be good enough for your needs. E.g. you can break any nvim window (floats, splits etc) into a separate external desktop window.

>definitely easier to configure

better defaults -> less work for writing a config file

>I would rather use VimScript than Lua.

NeoVim supports VimScript

I write short stories, blog posts and do commercial technical writing in Neovim and it is the best! It is the fastest and best way to write, I use Markdown and then can export to anything with Pandoc.

Very recently (0.6.0 I think) you can use the built in 'Thesaurus function'! You extract the magic function from the Neovim help files and put it in your init.vim: https://neovim.io/doc/user/insert.html#compl-thesaurusfunc ``` func Thesaur(findstart, base) if a:findstart let line = getline('.') let start = col('.') - 1 while start > 0 && line[start - 1] =~ '\a' let start -= 1 endwhile return start else let res = [] let h = '' for l in split(system('aiksaurus '.shellescape(a:base)), '\n') if l[:3] == '=== ' let h = substitute(l[4:], ' =*$', '', '') elseif l[0] =~ '\a' call extend(res, map(split(l, ', '), {_, val -> {'word': val, 'menu': '('.h.')'}})) endif endfor return res endif endfunc

set thesaurusfunc=Thesaur ``And you need to install the tiny dependencyaiksaurus`. On Centos/Rocky/RHEL 8 it wasn't available, but aiksaurus-1.2.1-38.fc28.x86_64.rpm from an old Fedora works perfectly.

Now just to the end of a word and ctrl x t and you get an awesome Thesaurus!

here is a link to one that already has it

If you don't like that, you could probably do a nnoremap :terminal <c-w>N

I can't guarantee that the second option works, but the first one works out of the box

Neovim tends to have a batteries included and sane default approach, while Vim tends to require you to compile it with features you need and has a backwards compatible focused set of defaults. As a full fledged editor neovim tends to be lighter weight, and as a bare bones editor vim tends to be lighter weight.

Here’s a more through guide on the differences: https://neovim.io/doc/user/vim_diff.html

The bot linking to the wrong page. The correct page should be at https://neovim.io/doc/user/vimindex.html

This bug has already been reported at https://github.com/heraldofsolace/VimHelpBot/issues/40

http://vimcasts.org/ is still one of the best resource out there for an overview of many different parts of Vim. You can go through the back episodes at http://vimcasts.org/episodes/

Otherwise, the User Manual (:help user-manual) is also very good, and will likely cover a lot of "unknown" commands. It's much more readable than the regular help files (but that's expected, the help files are a reference manual). But this isn't a website, unless you read from https://neovim.io/doc/user/usr_toc.html !

If you have the time I’d really recommend getting your own config with some inspiration from other configs. Otherwise you could consider looking into a preconfigured vimrc (or init.vim for neovim).

I don’t have a good list of preconfigured vimrcs, but heres a list for preconfigured neovim configs (and neovim only plug-ins) https://github.com/rockerBOO/awesome-neovim#preconfigured-configuration.

Regarding neovim, most vim configuration is compatible with it. The main differences, that are taken the most advantage of, are in it’s support for lua (you can write your entire configuration in lua), tree-sitter support, and in it’s native LSP support. Here’s a good resource to find the differences in depth https://neovim.io/doc/user/vim_diff.html .

Regardless of whether you choose to switch to neovim or stick with vim, https://github.com/neoclide/coc.nvim seems like a decent modern plug-in to include as it adds lsp support along with other things in it’s ecosystem.

If you are interested, I could provide a list of solid neovim plug-ins and chunks of vim compatible config.

open_float is in diagnostics and is specifically for diagnostic windows. No idea if you can round them: https://neovim.io/doc/user/diagnostic.html

UI customization: https://github.com/neovim/nvim-lspconfig/wiki/UI-Customization

There are a lot of different menus and windows that you can apply borders to. An excellent place to get started with finding all the different ones you can style is by looking at dotfiles. Akinsho, a community pillar, is an excellent place to start. For example, he styles a few lsp windows here: https://github.com/akinsho/dotfiles/blob/41f327dd47d91af42d1ed050745b85f422b87365/.config/nvim/plugin/lsp.lua#L184-L194

Currently in limbo between emacs(evil-mode) and neovim. After a lot more time in neovim, i lean ever so slightly towards emacs.

There is a noticeable 'snappiness' to most things in neovim as you mention, and i would agree that editing in neovim is overall more smooth, few if any 'hiccups'.

However, neovim is a complete black box. Once an instance is started, you cant get anything in or out of it (without using some additional tool like neovim-remote, which i found unbearably slow even against a single instance of neovim). This makes integration with other tools difficult/impossible. With Emacs, this is all very easy.

The other complaints i have with neovim arnt even a problem of neovim, but a consequence of its philosophy. If you would like to have any cohesive vim/terminal experience with the software you use, you'll now be a shepard of countless other tools, their binaries, their configurations, and however you glue them together. With Emacs, everything is basically under the same roof, speaking the same language. Emacs greatly simplified my setup.

Finally Im not sure neovim has the same trajectory as emacs, as much as i would like such a thing. Looking at neovim roadmap:

The promising 7.0+ features

> TUI as a remote UI ($NVIM, --remote)

right next to distinctly not emacs

> Embed Neovim everywhere

That being said, i do believe in neovim a little more than emacs despite its long history. The devs of emacs just does not seem as concerned with the 'hiccups' as i am.

Truly in limbo.

Lua actually knows a lot about vim internals (see api docs. there are a lot you can do without ever touching viml.

There is still a gap tho, that's why Lua plugins sometimes need to call viml stuff. at some point I believe Lua will be able to access everything.

While I agree that plugin devs have several language options to choose, writing in Lua is still, in my opinion, preferable. It will be less complex (as in less code spread), potentially faster, since the plugin will not have to interface between two processes/languages

There's an issue with this part:

> # Insert mode clipboard pasting > > Control-v is a common system level shortcut to paste from the clipboard. So why not use it also to paste from the system clipboard when in insert mode. > > inoremap <C-v> <C-r>*

When running in X11 (and I guess other display servers or systems), * is the PRIMARY selection, which is the last selected/highlighted text, whereas + is the CLIPBOARD selection, which works with the usual system clipboard. Unless you use a clipboard manager that syncs the PRIMARY and CLIPBOARD selections, this will usually paste something else you don't expect. This mapping should be:

inoremap <C-v> <C-r>+

more info in <code>provider.txt</code>

Thank you! In my case I wanted to truly master the VIM key binds, I was inspired by this Ben Awad's video. I had used the keybinds before, but I just ended up defaulting to VSCode's UI (I really wanted to archive not using my mouse when developing, really easy with a Dynamic Window Manager). Overtime, I developed my own "IDE" (through plugins) which really makes you appreciate the features other IDE's include, I even rewrote my whole config in lua once NVIM 5 was released, I haven't used VSCode in 6 months, though moments like this can really frustrate me, you don't actually need to build something from scratch you can use a prebuilt vim distribution like nvchad (I actually replaced some of my old plugins with theirs by checking their config.)

Todo.txt for management on Neovim running Linux. I usually try to keep it simple, since todo.txt manages single tasks in single lines of text.

Linux or neovim are not required, you can use todo.txt management in many other (user-friendlier) programs.

What kind of customizations are we talking about here, exactly? Generally speaking, the "vim way" to override a plugin is to place your changes in either ~/.config/nvim/after/plugin or ~/.config/nvim/plugin, depending on whether you wish to alter the existing functionality or replace it outright.

Technically I'm using plugin as an example here: your modifications should go in the appropriate runtimepath directory.

However, if your changes are extensive, you might wish to consider forking the plugin's repository and installing it from your fork. This allows you much greater flexibility in rebasing your changes on top of newer versions, especially when a conflict inevitably arises.

Either way, you should still be able to maintain your dotfiles repository without having to remove the .git folder of any plugin.

You should run VSCode without any problem, but all you need is a compiler and a text editor to write your code into.

And those don't need any special specs at all.

For the compiler, I would recommend GCC you will download the MinGW development suit and only choose the C compiler, as for the text editor you could I would recommend Vim, you can learn the basics in just a day, or you could use Notepad++ and with those two you could write any C program you want.

You use {noremap = true, silent = true} a lot in your mappings and could just use a variable to have a single source of truth instead.
Instead of using vim.o/bo/wo in your settings, you could just use vim.opt, and could even alias that to something shorter, like local set = vim.opt, with the outcome being set.number = true. That's longer than what you currently use but improves readability.
You have some options redundantly set, such as syntax = enabled, given that neovim sets some by default (https://neovim.io/doc/user/vim_diff.html). You have autocommands mixed with options, which feels non-modular and kind of messy despite being kind of related, I guess.

Contrary to dmccammond's opinion, these feel verbose and kind of unorganized.

I don't use vim, but out of necessity I have one installed. There are a few pieces of thoughtless software that implicitly depend on a "visual". (Yes, I know the $EDITOR trick.) I wish it would just go away. It's a terrible editor with an exceedingly hateful programming language, the few redeeming features it has are completely overpowered by its garbage UI.

I posted this link so /u/xxdavid8 can check whether jump is already available, or maybe reuse some parsing code, or contribute/fold jump into the main package.

The last time I checked, some line-marking and search related plugins wouldn't work. That's from 9/12 months ago. Also, the memory usage was higher.

I visited the official list of diffs and it does look shorter now. Maybe it's time to revisit.

What works is setting the LspReference*Type* within the ColorScheme event.
I didn't test, but try something like this:

if client.resolved_capabilities.document_highlight then vim.api.nvim_exec([[ augroup lsp_document_highlight autocmd! autocmd CursorHold <buffer> lua vim.lsp.buf.document_highlight() autocmd CursorMoved <buffer> lua vim.lsp.buf.clear_references() augroup END

function! CodeDarkCustom() abort hi! LspReferenceRead ctermbg=237 guibg=#303030 hi! LspReferenceText ctermbg=237 guibg=#303030 hi! LspReferenceWrite ctermbg=237 guibg=#303030 endfunction

augroup ColorScheme autocmd! autocmd ColorScheme codedark call CodeDarkCustom() augroup END ]], false) end

I updated the post to include the :checkhealth results. I noticed that it wanted me to set g:python3_host_prog, so I went to my init.vim and put this line: let g:python3_host_prog=\C:\Users\Brian\AppData\Programs\Python\Python39\python`Which was the path to my python executable. However, it returns this error when I start up neovim:Error detected while processing C:\Users\Brian\AppData\Local\nvim\init.vim: line 40: E15: Invalid expression: `C:\Users\Brian\AppData\Programs\Python\Python39\python` E15: Invalid expression: `C:\Users\Brian\AppData\Programs\Python\Python39\python` Press ENTER or type command to continue`

So I'm not sure what's going on even though I followed the documentation

Yes, you can. The docs are here: https://neovim.io/doc/user/provider.html

In short, create the venv, activate it, install neovim, pynvim, etc then add the path to the venv python to your init.vim:

let g:python3_host_prog = expand('~/path/to/the/venv/bin/python3')

Run :checkhealth when you are done to make sure that everything was set up correctly.

Help pages for:

<code>api</code> in api.txt

Lite is a text editor written in Lua. You can write plugins in Lua too.

NeoVim also lets you write plugins in Lua, but if you're not a lover of Vim keybindings, you may not find that suitable.

Help pages for:

<code>lsp-highlight</code> in lsp.txt

Help pages for:

<code>lua</code> in lua.txt

Help pages for:

<code>'shortmess'</code> in options.txt

Help pages for:

<code>'shortmess'</code> in options.txt

Help pages for:

<code>plugin</code> in usr_05.txt

First I want to make something clear: I'm trying to find the Language Server (not Language Server Protocol, I'm using coc for that) I am using for Coc. I just realized that the documentation I was reading was referring to an LSP, a language server protocol, not a language server. How can I find what language server I am using?

https://neovim.io/doc/user/vim_diff.html#vim-differences

I'll point out that putting your vim configs in ~/.config/vim is fairly trivial to do and I think there are far bigger differences between them to consider in making a choice. I prefer nvim's API, but vim's terminal implementation, for example. I personally don't think there is one obvious winner for everyone.

Help pages for:

<code>grep</code> in quickfix.txt

Others have already given you the better solution, but just so that you know what went wrong: `vim.cmd` takes a string as a parameter, representing the vim command: https://neovim.io/doc/user/lua.html#vim.cmd() whereas you gave it what is an invalid expression in lua.

The correct way using `vim.cmd` would've been `vim.cmd("let g:gruvbox_contrast_dark = 'hard'")`.

Help pages for:

<code>lsp-faq</code> in lsp.txt

Help pages for:

<code>remote-plugin</code> in remote_plugin.txt

Help pages for:

<code>:syn-sync</code> in syntax.txt

What is Reddit's opinion of Neovim?
From 3.5 billion Reddit comments

➔ Neovim website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

What is Reddit's opinion of Neovim? From 3.5 billion Reddit comments

➔ Neovim website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

What is Reddit's opinion of Neovim?
From 3.5 billion Reddit comments