Major version can make someone think nvim is still unstable. My experience is the opposite.
I have being using it for 2-4 years (can't remember exactly) and got the same 0 problems I run into Vim. Earlier versions required you to recompile NeoVim to enable new features for plugins.
Yesterday I installed NeoVim in my new laptop and it was a smooth experience: Installed it using Ubuntu package manager, installed Vim-Plug for managing plugins, copied my old init.vim (or .vimrc), run vim and everything in order.
I am really happy with NeoVim. I faced no problem with it that Vim could not resolve but I know the insides being a better ecosystem for core and plugins developers, so I will stick with it.
I tried jumping boat to nvim something like a year ago. One of my plugins ran into an issue, so I came back. A better question for us "old-vimers" is not "is nvim stable, because I'd like something modernized", but rather "what does nvim have that vim doesnt". I'm actually asking. My short glance led me to believe that it's got two things going for it: a) smoother interop with other "modern" tools b) cleaned up codebase.
I'm using the word "modern" in a derogatory fashion to underline that we often mistake new for good.
The major reason I use neovim is because with the addition of :terminal command I no longer need to remember tmux commands and with the add-on neoterm I have a one button command to send the current selection (or line) to whatever terminal I please.
This means that when developing code in any language that has a REPL I can test it out as I develop line by line.
I've been looking for something like this in vim for a while (something like Emacs + ESS). I've found a few plugins and workarounds using tmux, but nothing as smooth as you said. I'll try it out.
I got frustrated with how slow syntastic was too, but I have just upgraded 8.0 and have switched to using https://github.com/w0rp/ale for asynchronous linting and it's working very well.
I'm interested in neovim as well and I think you're asking a legitimate question. I would also add that if neovim is developer-friendly(er?) then that could also be a reason.
Agreed. I've been using it for about 2 years without issue. I've also recently (within last 3 weeks) installed it on a fresh OS X install (on two, actually) and the experience was without incident and hassle free.
The only thing that I had issues with was plugins using the remote api from node because I kept forgetting to install node_host (which was mentioned in the README and I just overlooked). Once I remembered to install that (and node locally), everything just worked.
I have been using Vim as my primary editor for many years and am happy with it. People I know who use developer editors are split between Vim and Emacs. Neovim usage is minimal. Why? It is an honest question.
I see developers of the editor happy, which is a good thing, but IMO to get more users NV must show why it is better from a user perspective -- have several demos on the powerful things easily achieved with NV that are painful with Vim (via plugins is OK).
If NV devs can do this, it will go far. If not, then the case for an upgrade hasn't been made yet for most users. My 2c.
I'm an Emacs user and that's because the Unix way doesn't quite work out well in practice: composition is hard, requires textual transformation with many possible edge cases as glue which is hard to build and maintain and is bug-prone, and interfaces are cryptic, only partly portable and inconsistent. Elisp on the other hand is a nicer primitive for building my day-to-day tools: Uniform data format everywhere; buffers and processes are nicer primitives as an interface to other programs in the system; single, extensible programming language (with lexical-scope added and threads coming in, Elisp is quite pleasant to program in in fact).
NeoVim seems to bring these qualities into Vim sphere, giving the users and extension developers (in Emacs many extensions are apps themselves) better primitives to develop tools and applications, and allow to abstract-away Unix userland which is way too low-level and as I said above, not that friendly and helpful environment to live in. It holds on to what makes Vim interesting (modal editing, the range-command-object-movement style editing commands, ex mode) while adding a better API (VimL is...).
I used vim and neovim for quite some time and eventually switched back to Emacs. The "you do not have to leave your environment" is actually quite nice. magit and org-mode are awesome. Color scheming is actually easier.
Still having trouble with identation, though. vim is just smarter ...
FWIW, I disable electric-indent globally and use C-j instead of RET which indents after new-line (it's bound to electric-newline-and-maybe-indent, I believe it's the default binding):
C-j runs the command electric-newline-and-maybe-indent (found in
global-map), which is an interactive compiled Lisp function in
‘electric.el’.
It is bound to C-j.
(electric-newline-and-maybe-indent)
Insert a newline.
If ‘electric-indent-mode’ is enabled, that’s that, but if it
is disabled then additionally indent according to major mode.
Indentation is done using the value of ‘indent-line-function’.
In programming language modes, this is the same as TAB.
In some text modes, where TAB inserts a tab, this command indents to the
column specified by the function ‘current-left-margin’.
Without neovim, vim wouldn't have gotten the async features. The fact that it's a community driven project and not dictated by one single BDFL makes it a lot more sympathetic for me.
> Without neovim, vim wouldn't have gotten the async features.
With this I wholeheartedly agree. Without NV async would likely still be on the Vim wishlist. And if neovim wants a small donation I will gladly do that to say thanks.
However, now Vim does have async support as well, this use case is gone. NV needs to find the next one (and next and next). If their code is cleaner and easier to work on they will permanently overtake vim in features sooner rather than later.
Vim is also community driven. Having a BDFL doesn't mean that the model is bad. Python, Linux all have BDFLs and they are blossoming.
Also, saying that Vim wouldn't have gotten the async features without Neovim is wrong. It would have come in sooner or later, Neovim sure made it a priority.
The main reason NeoVim exists at all is because Bram Moolenaar refused to accept any patches for async support. People already did the work for him and he didn't want it.
So they decided to write their own text editor that supported async plugins. Bram got butthurt and didn't want to lose a large portion of his user base, so he added async support.
NeoVim's first public release (version 0.1) was released in December 2015. [0] And you can see that Vim development really picked up in early 2016. [1]
Coincidence?
Anyway, both text editors are awesome, and Vim is better off now that it has competition. The async features would never have come without the competition of a rival project.
> The main reason NeoVim exists at all is because Bram Moolenaar refused to accept any patches for async support. People already did the work for him and he didn't want it.
That is an unfair description. When it was submitted to Bram it was incomplete and not completely functioning, and he did receive feedback on it.
> The main reason NeoVim exists at all is because Bram Moolenaar refused to accept any patches for async support. People already did the work for him and he didn't want it.
This is not true. If the work was not complete and not as how the lead maintainer/developer wants it. It is highly unlikely that it would be merged. I suggest you actually go and read the mailing list when this happened. I have seen it.
If I remember correctly, the guy kept changing his patch to meet Bram's conditions, but then Bram kept adding more requirements, to the point where it seemed like Bram was just making up excuses for not accepting the patch.
I could be wrong though. Please can you link the mailing list. (I can't find it) I'll read it and take back what I said, if that is the case.
This thread is basically over already, but here's a few links to what I think are relevant messages from the discussion (And from these links you can largely see the whole thing, though there's a few other threads spread out elsewhere):
Personally the last post is the most important. He's basically saying that he knows there's clearly problems with his patch, but that he doesn't want to work on it until Bram takes the time to look at it and tell them what's wrong. He wants to push it in even though it's not 100% functional, to the point that he suggests merging it and calling it "experimental-timers".
The above isn't 100% related to Neovim, but below is the thread where Thiago Arruda essentially decides to create Neovim, and the other thread is brought up in this one which is why it is relevant:
I recommend looking at the dates, Thiago posted the concept patch 12/4/13, and Christian ZyX responded 5 days later, and then Thiago responds that he's done working on the patch because of a list of reasons: One being he has heard stories of long response times from the Vim developers, Two being that 5 days was too long of a response time and that Bram hasn't responded to his patch, Three being that it was too complicated and he wouldn't be able to make it work, and Four being that he didn't want to work on it if it wasn't guarantee to ever get into Vim.
I found the fork / refactor of VIM by NeoVIM to be very hostile and even naming itself "New Vim" made me not want to support NeoVIM. I have been using VIM since it was on my Amiga in the mid 90s.
VIM has been a stellar project that is due a lot of respect. Even the funding for VIM is reflected back to giving to Uganda children charity.
> NeoVim exists at all is because Bram Moolenaar refused to accept any patches for async support. People already did the work for him and he didn't want it.
Untrue: "It's going to be an awful lot of work, with the result that not all
systems will be supported, new bugs introduced and what's the gain
for the end user exactly?
Total refactoring is not a solution. It's much better to improve what
we have. Perhaps with some small refactorings specifically aimed at
making Vim work better for users." Brian Moolenaar https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...
NeoVIM kind of said that VIM was just a mess and it would be impossible to grown past where it is. To me this was worst then Ubuntu having it's own Unity and Mir. This was just drama and seemed over the top disrespectful to Brian.
It's offensive for neovim to call itself neovim but it's alright for vim to be called vim?
For the record, vim means Vi iMproved. Bill Joy invented Vi, not braam.
Neovim is very much to vim what vim was to Vi.
And Vi is what should be credited for the more important concepts found in those editors and their reproduction in IDE like the various Vi like plugins.
Braam losing a spiritual monopoly on such a great editor concept like Vi can only be a good thing.
For something you call worse than unity, it works pretty nicely, stable, fast, with far more readable code and is already on its way to become a great embeddable editor so that we can use the real Vi in IDE instead of pale imitations.
Your wrong in terms of how VIM came about and name.
VIM originally meant "Vi IMitation". It wasn't till 1993 that it became "Vi Improved."
Actually VIM is not a direct fork of VI. VIM comes from Stevie editor from Atari ST and Amiga days. (I actually started with Stevie).
Here is the tree from ed to VIM
ed > Bill Joy and company then made em > en > ex AKA vi
Joy left development of VI in June 1979 and joined corporate life working with BSD.
vi (Unix\BSD) > Stevie editor (Atari ST) > VIM (Amiga)
Then chaos hit. From 1981 onward clones and implementations were incompatible and progress kind of grind to a halt due to license. That is when Stevie editor hit and then when Bram Moolenaar made VIM. He reimplimented it for Amiga and added features one being plugins. Vi had no plugins and very little customization.
Here is why your analogy is wrong: LICENSING "While commercial vendors could work with Bill Joy's codebase (and continue to use it today), many people could not. Because Joy had begun with Ken Thompson's ed editor, ex and vi were derivative works and could not be distributed except to people who had an AT&T source license."
So it is not at all like this fork. I find that people have taken sides without even knowing the history of VIM and make assumptions.
I think the reason people are downvoting you is that after the (interesting) historical detour, you say "it is not at all like this fork" when in fact it is still exactly like this fork as far as the main point of the parent post is concerned.
Due to _________ we are making a clone of this other product, but one that fixes ________, and therefore we are also attempting to co-opt the name a cutesy way so that people understand this is supposed to be, while not exactly the same thing, an equivalent thing (but with __________ fixed).
> Due to ________ we are making a clone of this other product,
LICENSING (owned by AT&T the Oracle/Apple Grand Daddy of lawsuits in the 80s and 90s) and it was a port on an unsupported operating system, Amiga OS.
Also it was a clone of Stevie more so then Vi.
> but one that fixes ________
Vi TO RUN ON AMIGA OS (ADDED PLUGINS and CUSTOMIZED SHORTCUTS plus many other features not found in VI.)
Nothing in Neovim especially looking at VIM 8.0 is added but it is a refactoring with compatibility of plug ins with a cleaner code base.
I feel like people on NeoVIM side never really read the primary fights about the patch or understood why BDLF took a stand for a code more to his liking.
Yes, competition is very healthy and good for an ecosystem overall. Though the entire sector my business operated in eventually got shut down due to unscrupulous competitors, can't deny that competitors really lit a fire under my butt compared to the first year, when I was in the field alone.
I use Vim with a customized `.vimfile`, but rarely if ever do I tinker with a lot of plugins. If I'm doing "development", then usually I'm using a JetBrains IDE product with the IdeaVim plugin. If I'm in vanilla Vim, then it's because I'm just doing text editing from a shell, and have no need for a lot of plugins.
This is anecdotal speculation, but I imagine that most Vim users are in a similar boat. I talk to so many lifelong Vim users who have never even heard of "pathogen" or other plugin management systems. I'm pretty sure that heavy plugin users are the minority.
Most people who seem excited about NeoVim (or even talk about it at all), fall into three categories:
1) Heavy plugin users, who want plugins with some feature not well-supported by Vim.
2) Developers who would like to embed Vim within their own applications, but find the classic Vim codebase or license unsuitable for this.
3) "Ideologues". People who don't like Bram Moolenaar. People who wish he would have accepted a pull request that he declined or ignored. People who wish he would release Vim more frequently, make it more trendy, or bloat it up with this or that new feature. People who just don't like the way that the Vim project is run, ideologically speaking. (EDIT: i.e. the brigade crowd who's downvoting every comment that isn't unqualified praise and support for NeoVim.)
So like I said, I'm pretty sure that the overwhelming majority of Vim users do not fall into category #1. And the other two categories are tiny subsets of that first one. So to turn the question around... why WOULD people go out of their way to abandon the default, and flock to something else which might drift away from compatibility over time?
Competition brings the best out of people.
New ideas should be accepted even if it makes things drift away from compatibility. BSD started w/ unix code and eventually refactored all that old code out, doesn't make it a bad project simply because it's no longer a drop in replacement for unix. It serves other purposes.
I am a developer using vim & neovim daily. My setup before VM/container popularity was mostly ssh into a remote dev box, then tmux+vim there on the remote host. Tmux mostly for its split-pane feature which I like better than vim splits.
Now since I can do most of my work locally, neovim's terminal support has, for me, completely replaced my use of tmux splits. Having moved all my split usage out of tmux into neovim has simplified my setup and keybindings. And I grok and am more comfortable now with vim/neovim splits.
It has vi in the base system, specifically `vim-tiny`. Vi is mandated by POSIX, so pretty much every distro includes some minimal version of it in the base system. `nvi` is also used sometimes instead.
Can you please elaborate how you make use of the built in terminal emulation of neovim? Whenever I see a mention I think "neat" but have yet to integrate it into my workflow.
Not parent, but I use Neovim and Ranger [1] filemanager and I have a shortcut to open Ranger in a split or full window from which I can browse and open a file. You can do this only because Neovim has a built-in terminal. This may end up replacing vinegar [2] as my in-VIM filemanager.
Lazy version would be `:vsplit | lcd %:h | term ranger<cr>`.
`vsplit` splits the window vertically. `lcd` sets the bufferlocal working directory which is a new feature in neovim. `term ranger` launches the terminal emulator. If you wanted to be fancy you could add a toggle that reuses the same ranger instance which'd add an additional ~10 loc.
I use it a lot when doing exploratory SQL work or writing queries. I can tinker with my query in one pane and send it over to the `psql` repl in the other.
I do use psql's `\e` command to open the previous query in your `$EDITOR`, but that only lets me get the single previous query, and throws out any comments.
Like a lot of other IDEs, it is convenient to have a console to focus over to then run ad-hoc cmdline stuff or run tests for the currently active project. This is what I use :terminal for the most. It was helpful for me to setup the below keybingds for focusing back/forth between a :terminal split and my "editing" splits:
I use it to either run microservices for testing, or for testing code in the erlang shell. It's MUCH easier to copy and paste inside vim and be able to copy logs out into a buffer to run sed expressions on it, than if I were using another terminal.
I set up a new machine a couple of days ago. Looked for neovim in FreeBSD ports. It wasn't there. Shrugged and installed vim.
I'd happily have switched if only for the code quality reputation. But it needs to be easy - no, that's too weak a word, it needs to be trivial - to install in the usual way I install things.
Regardless if you feel like if the NeoVim refactor is worth it or not we can all agree that it is tremendous effort to modernize code written over the course of decades. Great job guys on another release!
This release fixes one of the biggest bugs with asynchronously embedding Neovim (some input states would just block the API), and makes ActualVim more reliable as a result. Neovim embedding works pretty well now, and will only get better. I'm hoping it will be possible soon to embed the entire Vim experience into another editor with little to no tradeoffs on either side. I've been impressed when interacting with the Neovim developers.
I'd love to see neovim embedded in Firefox, and have it be just a standard part of every text field. Having a seperate editor window pop up as with the It's All Text extension is just not the same.
It'd also be great if there was a way to have neovim "wrap" arbitrary shell commands, kind of like rlwrap[1] does, only with full vim editing features available instead of the relatively crippled readline.
I wish something like this were available for Chrome. My Firefox use has been declining. Not really sure why. Though the termination of the addons language (xul?) in favor of webextensions is probably a big reason.
> Actual uses an embedded Neovim instance to accurately manipulate each Sublime Text buffer as though you were editing the text directly in vim, without breaking any Sublime Text features (aside from multiple selection for now).
- It also breaks the automatic (while typing) completion and snippet suggestion popups (though Sublime's autocomplete has been wired into Vim and works great there)
- Sublime's undo works but isn't coalesced properly while you're in Vim mode (but Vim's works fine there).
I use Neovim on daily basis. It works really well. It requires tremendous efforts and love to transform a huge archaic code base into a much modern one. Thanks, Neovim team!
This can be said for any rewrite. Let's wait and see what happens to Neovim's code in coming 10-15 years if it can last that long. When you have to support all the legacy systems and all types of OSes out there, crap is going to come in the code.
I understand why they started neovim, but don't think the split between vim 8 of today and neovim is a good thing. Makes me think of emacs vs xemacs but worth because they use slightly different dialects of vimscript (closures, currying in vim 8, different api for asynchronous calls). I personally wish they'd meet on some common, standardized ground. This would require both parties to accept they are not alone though.
Edit: I realize that "Vim 8 features: partials, lambdas." might solve part of my problem.
Can you back up this claim? I think it's not true and authors of both projects respect each other. They simply have different views regarding backwards compatibility etc.
I think 'hostile' is a bit harsh. I'd say 'infinitely reticent to large changes'. All the neovim authors wanted, was a list of blockers needed to merge their async patch. Bram would never give them that, always coming up with one more change. I've seen this pattern of infinite reluctance before, especially when communities depend heavily on one maintainer. its not about async and the specific semantics of the patch after a certain amount of time, it's about deeper issues like project vision, control, and perhaps trust. https://groups.google.com/forum/m/#!topic/vim_dev/-4pqDJfHCs...https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...,
All they wanted was to fork the project to "clean up" the code in ways they wanted, manage the community themselves, etc. It wasn't like all their patches were flawless and Bram just wouldn't accept them.
Just dumping any old code into a project the first time it's demanded is a sign not of enlightened maintenance but of gross negligence. It's good if there's a lot of feedback on patches, it's not some kind of aggression.
What are you doing that makes Vim lag? In my experience (on much weaker hardware) it only lags noticeably when you do wildly unusual stuff, e.g. huge files or files with huge lines.
On an old netbook (remember those?) Vim would lag just entering text in insert mode when I was editing LaTeX files (and only LaTeX files as far as I could tell). Slowness of LaTeX syntax highlighting is a known problem (the help files have a section called tex-slow). Trying all the suggestions there didn't speed things up enough for me. I tried editing without syntax highlighting for a while (this did work and completely solved the lag), but eventually just switched to Emacs.
Managed to do more with nvim - yet to try syntactic again, thatll be the real test) but so far amuch more stable experience movement wise. (the files i work on are huge and im tasked with refactoring, so i cant avoid the hugeness)
The efforts of Neovim team are well-intentioned and we are seeing it shaking the ViM development. (the previous major version from (7.0) 2006, before it (6.0) 2001).
I'm currently using vim and I'm quite happy with it. I don't use many plugins, so better support for plugins is not very helpful to me. Are there other reasons why I should switch to Neovim?
Faster startup, mouse works as you'd expect in a regular desktop app. Switch panes, tabs, open new tab, scroll panes, resize panes, select ranges, all in the terminal. I know not using the mouse is one of the reasons why one would choose vim, but the mouse really is faster/more intuitive in some situations.
Using a mouse is not faster if you really know how to use vim. I guarantee I can get to any line in any window in any tab faster than it takes for my hand to even reach the mouse. Same for resizing splits, selecting ranges, whatever. It's only more intuitive if you're stuck in a GUI mental model. Disable mouse support and learn to navigate vim just like you learned to edit in vim.
Not trying to come off as confrontational, just my 2¢.
It should be possible to use something like EasyMotion to resize panes, taking the guesswork out of it and making it as fast or even faster than using the mouse.
Being "stuck in a GUI mental model" means I use IDEs for most development I do instead of vim/emacs (which I guess would be the extreme of being stuck in that model?). At the end of the day using my mouse to open a file doesn't impede my ability to code in the slightest.
I've never understood the almost subtle elitism behind being able to use Vim without a mouse because "moving your hand to the mouse is slow". If a problem is so simple my writing/editing a solution for it is constrained by... the time it takes my hand to move to my mouse... I usually just fire up nano.
It's not about elitism, it's about using the tool you've chosen efficiently.
If I used the IDEs you use, and you suggested to me a way of using them more efficiently, I wouldn't accuse you of elitism. I'd thank you for showing me something new and improving the way I work.
Have you ever witnessed somebody using a mouse to move between form fields? My bet is you at least thought about telling them they can use the tab key. You probably wouldn't expect them to come back with some comment about the subtle elitism behind using the tab key.
If I told them they didn't really know how to use a browser because... they didn't know to use tab to move between fields... I wouldn't be surprised in the slightest if they came back with some comment about the subtle elitism
Ha, fair enough. But that really only shows that my example wasn't great.
If you eat soup with a fork, you don't know how to use silverware. If you drive nails with a ball-peen hammer, you don't know how to use hammers. That's not hammer or silverware elitism.
IMO, using a mouse in vim shows that you don't know vim. You can still get the job done, but why not commit to using the tool as intended?
Most IDE's have fantastic fuzzy search and go-to-identifier tools you might want to try. I find it much easier to stay concentrated on a change when not needing to hunt files with the mouse.
The mouse features you describe are already available in regular vim; I have been using them since long before NeoVim existed. Are they improved somehow?
Do any of the plugins that you do use slow the editor down? Eg some completion plugins that parse code may not be the fastest. Neovim makes this asynchronous so it no longer blocks you're editing while its working away in the background.
The built in terminal is nice too (I use it to give me a "real" REPL for Clojure development)
> Are there other reasons why I should switch to Neovim?
I've switched back and forward between neovim and vim since last year. Most people won't notice a difference right now. I think around version 1.0 we'll start seeing people do some more compelling stuff with neovim.
I initially went to neovim because it had better support for color schemes. I usually develop in VSCode, and wanted a similar color scheme when I needed to make small edits on the server. Neovim had much better support for that, and acted like "normal vim" the rest of the time, which was awesome.
In Emacs the shell-mode allow me to use the shell as any other buffer, with random access and scrolling. I can cut and paste stuff just like in any other text buffer, manipulate the output of my session to save it to some file / send it to someone else, etc. IDK how it is in nvim but I'm quite pleased with shell in Emacs, can't go back at all. Though if you're using tmux or maybe screen you can probably do similar things.
If you're asking what good is a built in terminal, well, there's plenty of scenarios. One I'm facing right now is using GVim on Windows. Have you ever seen what happens when you type !dir in GVim, right now? It's really ugly.
The only thing that bugs me about neovim is that it seems to require workarounds to get the escape button to behave the same as in vim. When I press escape to exit insert mode, there is a small delay. If I press a key (e.g. 'j' to go down) too quickly after Escape, it inserts the 'j' and cancels what escape is meant to do.
In tmux I know of a workaround (iirc, 'set escape-delay 0' or something similar), but I wish I didn't have to change a tmux setting so one program can function. It's really annoying.. but ultimately worth it, I guess.
That said — to the neovim team: congratulations on reaching the 2.0 milestone!
I saw this thread, and I promised myself I wasn't going to plug Kakoune -- I think NeoVim is a great project and I want it to succeed. They deserve every bit of the praise they're getting. But I'm going to have to break my promise, because Kakoune has the exact feature you're after, and I'm using it right now. That, along with familiar keybindings, selection-oriented modal interface, tmux integration... I could go on. Kakoune is a modern modal text editor for your terminal, and it's worth trying!
Caveats: if you depend on plugins to give you an IDE-like experience in Vim, kak is not for you. Your vim plugins won't work. If you use Windows but don't want to use Cygwin, kak is not for you.
Kakoune is always super tempting to me but the plugin thing is a deal breaker for me. Not for IDE-like features but because limiting myself to vanilla vim motions feels like using a bad vim plugin by now.
At least surround.vim, targets.vim and a couple custom text objects.
I think the current goal is to let neovim instances to communicate p2p so that they transparently use the same session. Mostly because adding multi-tenancy to vim would be a living hell without adding much over that approach.
Has been a while since I have read up on that, though.
My first impression was not a good one. Its hardwired assumption of xterm control sequences, even when TERM says something else entirely, caused it to be unusable on my terminal (which understands DECSLPP as DECSLPP).
I use several. But this particular one is most definitely not xterm, nor dtterm.
Ironically, it actually implements both of DECSLPP and DECSCPP, but without the restrictions to only some sizes. So nvim could use these DEC VT control sequences to set the screen size. Unfortunately, there is no simple mechanism for nvim to know this. There's no terminal type that a user could set that would hint at this ability, let alone a termcap/terminfo capability.
Nonetheless, just blithely assuming that every terminal type in existence implements dtterm's idiosyncratic extensions to the DEC VT control sequence set is wrong. There is a way for nvim to be told that the terminal is likely to have dtterm's idiosyncrasies, or indeed xterm's. nvim even uses it to detect other terminal types with other idiosyncratic control sequence extensions.
It actually becomes usable once this bug is fixed.
I'd say the info provided in the github releases is interesting, but it doesn't provide the necessary oversight a general info text would give. Can't really say what happened. Even if it was a stabilizing release it would be nice to see that somewhere.
I don't know if it'an issue on my side, but I have not manage to do anything with the :terminal on Windows 7. It starts a prompt but I can not input anything in Terminal mode. I tried 'i' to go in insert mode in the terminal but it does not seem to work either. (To be sure this is not something in my vimrc, I tried with and without it). At that point I am not sure if this is a problem between chair and keyboard or a bug.
I have being using it for 2-4 years (can't remember exactly) and got the same 0 problems I run into Vim. Earlier versions required you to recompile NeoVim to enable new features for plugins.
Yesterday I installed NeoVim in my new laptop and it was a smooth experience: Installed it using Ubuntu package manager, installed Vim-Plug for managing plugins, copied my old init.vim (or .vimrc), run vim and everything in order.
I am really happy with NeoVim. I faced no problem with it that Vim could not resolve but I know the insides being a better ecosystem for core and plugins developers, so I will stick with it.