Vim 8.0 released
groups.google.comGiven the occasion, and given that vim is charity-ware software (http://charityware.info/), it would be cool to have some sort of HN-wide donation to ICCF (http://iccf-holland.org/).
Donation page: http://iccf-holland.org/donate.html
It seems that you can send bitcoins too: http://iccf-holland.org/bitcoin.html
Imho just mentioning HN in the payment description would be okay :)
Given Vim powers our industry, it'd be neat if pg or any of the other big members of our community donated a non-trivial amount.
There is very few pieces of software I could never imagine replacing in my toolkit. Linux? I use Windows, too. GCC? Clang gets some love sometimes. Languages themselves? I'm fluent in several. Shell? I used Bash for years, now I switched to ZSH, but could go back to Bash if I needed. Tmux? I could also go back to screen if I needed to.
But vim? There's no replacement for vim. vim changes how you think about programming, how you think about software development. It is this frictionless editor (I mean, yes, huge fucking learning curve, but so is programming in general) that, even 20 years later, I will never abandon (unless I'm doing Java, because... fuck Java outside of Eclipse or IntelliJ; and yes, I've tried using that one vim<->eclipse bridge, hell no).
Just to add to this, a couple years ago I was able to run a campaign to raise $5000 for Vim via Hacker Newsletter (http://hackernewsletter.com) all thanks to 38k great subscribers and sponsors. So while not officially via HN, it was unofficially. :)
We currently hold the top spot, although I would be happy to see someone surpass that: http://www.vim.org/sponsor/hall_of_honour.php
> There's no replacement for vim.
I'm used to seeing people say "vim" where "vi" is meant (of which vim is but one (much enhanced) clone), so when you say you could switch out gcc for clang, or bash for zsh, could you not switch out vim for (e.g.) nvi[0]? If not, why not?
nvi provides a minimalist implementation of vi. If you feel comfortable with the vi keybindings in other editors, nvi will likely suffice. However, many vim users expect scriptability, programming language support, and numerous other features.
The analogous comparison would be between bash and posh/dash, or between gcc/clang and the Tiny C Compiler.
I haven't used nvi in several years (mostly because, unlike nvi, vim has become universally available on the systems I use), but it's not minimalist. nvi has a number of features that the original vi does not. Perl integration and infinite undo are two examples.
nvi definitely provides more features than the original vi, just not nearly as much as vim. And it doesn't have a comparable ecosystem of plugin/package developers around it, either.
Is there a popularity dashboard of plugins that one could check to see what features vim users are enjoying that I've been living without?
http://vimawesome.com/ has a list of Vim plugins sorted by their popularity, measured by presence in dotfiles repos on GitHub.
For a conservative list of "essential plugins", see https://www.vi-improved.org/plugins/
"surround" and "targets" are indispensable for me.
Almost nobody is using Bill Joy's vi and most systems don't have it. They might have a symlink to vim named 'vi'.
Why would you want to switch out of vim ? It runs everywhere. nvi is completely different, all the configurations and so on. Syntax files, plugins, you can't just move those over.
You're assuming a vim-centric point-of-view. Believe it or not, I don't use vim that much, and so I have no vim configuration/plugins to worry about. nvi happens to be where I spend the bulk of my time since I've cared what flavour of vi I'm using. So, I haven't "switched out of vim". I am genuinely interested in "what I'm missing" though. I occasionally trawl though youtube to look for videos, but I mostly haven't had my mind blown. I think I -would- like horizontal (or would you call it vertical?) screen splits where I have a left screen and a right screen (nvi provides splitting arranged above/below ea. other), and to fold sections of my work too, so I could (using my imagination here): ma (mark 'a), go to some other spot in the doc and: \(backslash)'a (fold the text from "here" to the 'a mark). That'd be immediately satisfying. Otherwise, I think nvi holds up really well for me.
How about fugitive
http://vimcasts.org/episodes/fugitive-vim---a-complement-to-...
Someone somewhere uses elvis, but it doesn't make any sense to assume an elvis-centric point of view.
I haven't used nvi in many years, but for me, vim is much more than just the vi key bindings. Absolutely core features for me include folding and the various syntax-related features (filetype identification, syntax highlighting, filetype-specific logic, etc.).
I found that Emacs + Evil is a pretty good replacement for Vim. Nowadays there is also NeoVim.
I consider NeoVim a Vim, too, thus I don't mention it separately, even though a lot of the internals has been changed around. I wish them a lot of luck.
Evil mode in Emacs seems to be a bit of a crutch. I was actually an emacs user for awhile, and a lot of emacs' power imo comes from using emacs "the right way". I respect emacs and emacs users.
There is also Spacemacs, which imho, is much better than Emacs + Evil.
Spacemacs is Emacs + Evil...
But with a fantastic boilerplate that requires minimal set up and very easy ways to configure it.
plus that annoying space button
butwherewouldwebewithoutthespacebutton?
Re: eclipse. Rather than the bridge you might want to give vrapper (http://vrapper.sourceforge.net/home/) a try. I find it to be quite acceptable - much better than having no vim keybindings. It's very comparable to the jetbrain's vim plugin.
jetbrains vim plugin doesn't even let you define your own vim like keybindings. It is the worst vim plugin I've seen.
Actually, there is some minimal support for map keybindings. See https://github.com/JetBrains/ideavim
Interesting seems to have improved.
I use both. Vrapper is the best Vim emulation so far
JetBrain's Vim plugin is very high quality.
It's the only VIM emulation mode I've used that isn't completely annoying. I'm including spacemacs in that assessment.
I agree, it's just Good Enough. I mostly miss some add-ons like surround.
Surround support was just added in IdeaVim 0.46. From the release notes:
Support for vim-surround commands ys, cs, ds, S, enable it with set surround in your ~/.ideavimrc
:-o Thanks!
It's OK but I could never get it to do things beyond basic editing like window management right.
It's high quality as they go but not close to being a vim substitute in my experience. There are still tons of little things that don't work as expected.
so is netbeans's - it's a straight port of the vim source code to java
I came into Vim pretty happy with my other tools (a very-enhanced Sublime Text 3 and JetBrains IDEs)...I wasn't trying to learn Vim, I just had to. Vim is now basically my one tool. That and tmux...and more of the stuff I was using tmux's features for I'm doing in Vim. Both tools are definitely irreplaceable for me at this point, but vim much more than the other.
> I will never abandon (unless I'm doing Java, because... fuck Java outside of Eclipse or IntelliJ; and yes, I've tried using that one vim<->eclipse bridge, hell no)
If you're referring to eclim [0] FWIW I've found it to be an adequate way to have a vim centric workflow with a few excursions into eclipse. If you have proficiency with both tools and enjoy having an eclim server running in a eclipse window you'd get have access to the best features of both tools.
I'm still trying to use vim with java =P Someday I will be happy
Vrapper (http://vrapper.sourceforge.net/home/)
Its a very non-intrusive vim plugin for Eclipse, just does vim emulation and nothing else.
I've found it to be very pleasant to work with.
I did use this plugin for a long time. The best plugin so far. I want a plugin like this for Intellij :P
https://plugins.jetbrains.com/plugin/164 (IdeaVIM) is pretty good for intellij based ides.
actually I'm using this plugin. Not the better but helps to fell good
eclim ftw
the problem with eclim is that is slow for huge projects. I did use for some time
> Given Vim powers our industry
I hope that you're being sarcastic.
Nope. The only other popular editors I've seen people using is either Sublime which, although highly configurable, just ain't no vim; or, all the emacs users, with emacs being the only real competitor to vim. I didn't mean what I said as a slight to emacs users at all, I respect them and their editor, I'm just a huge vim fan.
Also, the same with Java only being used with Java IDEs, C# only being used with Visual Studio is also a notable exception to my "vim all the things" rule.
Probably different people have different views on the industry. I never saw anyone (but me) using vim. Programming: Eclipse, Intellij Idea. Administration: notepad, sometimes notepad++. For Linux it's KEdit or GEdit, depending on environment, I saw nano once. vim or Emacs are popular among enthusiasts, but for many professionals who's just makes living on it, those are gimmicks from ancient era.
I spent quite a lot of time mastering vim. It's beautiful editor and I could be incredibly productive with it, but I'm not sure that there are many people who'll do that.
Every so often someone will do a "what editor do you use?" poll here, vim is the top choice. Maybe it's not the most common in the industry, especially if you include the hordes of Java or C# only developers, but at least among HN devs it's the #1 pick.
A stack overflow survey (http://stackoverflow.com/research/developer-survey-2016) had plenty of vim users and that includes us c#/java hordes.
Atom is reasonably popular, and Visual Studio Code is getting there.
So you see the comfort of using IDE (eclipse or intellij) with languages such as Java. Do you feel a similar comfort in vim? with which languages?
Not the parent but I have the same reaction, and I wouldn't describe my experience in big IDEs as "comfort", just less pain. I use them with Java only out of necessity, and only on huge projects I didn't have a part in designing up front.
Every other programming language I've used a lot of (spanning from assembly to lisp) I've found it most pleasant to work in vim, even in large projects. I suspect the only other environments I'd want an IDE would be for iOS development and C#.
I found Vi to work perfectly well for C#.
Visual Studio would have been better, if I could have got a decent Windows desktop to span both of my monitors. But since my employer at the time didn't want to get a Windows PC or get a Visual Studio license for this Windows desktop application project, Vim + Samba + SSH were a workable substitute.
I don't know if it's still there, but at one point (some?) MS licenses had an audit clause that would allow the BSA or MS to raid your employer at their expense. That could be one reason for a non-MS shop not to want to get any MS licenses.
Java and C# were both designed to be used in language specific IDEs (C# inheriting that from Java). Using Java outside of a Java IDE is insane.
C, C++, Python, Ruby, JS, Erlang, Perl, etc, just require a relatively sane text editor, no full scale heavy weight IDE features needed. So, yeah, vim does everything I need there.
"Vanilla" C++ is one thing, but when it comes to using comprehensive frameworks such as Qt or wxWidgets, I guess you have similar reasons (to Java and C# with their "batteries") to use IDE.
Nano
Are you seriously suggesting that nano is a valid replacement for vim?
If vim for you is "the thing you edit config files with when sshing to a server," yes, it is. As a full-fledged development environment, it's not.
In the context of this thread, it is not a valid replacement.
I was able to explain to a first time Linux user how to edit a network/interfaces file using nano. I'm not sure I could have done that with vim. That makes a difference in my book.
Neovim was largely responsible for pushing vim to add many of these features like async[0]. If anyone wants to donate towards this kind of pressure, there are links here: https://neovim.io/ [Edit/disclaimer: I have donated in the past.]
Neovim is like the Chrome of the web. A great editor, but also a great forcing function for the ecosystem.
> Neovim was largely responsible for pushing vim
Did Bram Moolenaar tell you that? Otherwise, none of us know what motivated him.
Neovim fans seem to hijack Vim discussions frequently. Sometimes people want to talk about Vim.
> Did Bram Moolenaar tell you that? Otherwise, none of us know what motivated him.
I don't think this is a subjective matter? The sequence of events was:
1. async feature was proposed in 2014 and earlier, Bram was opposed to the idea in general
2. neovim was created to integrate async and other improvements
3. lots of plugins started supporting neovim's async
4. vim comes out with its own async feature
You're welcome to ask Bram what motivates him personally, but I'm comfortable with my judgement of causality to the ecosystem as a whole.
> Neovim fans seem to hijack Vim discussions frequently. Sometimes people want to talk about Vim.
You may talk about vim, that's fine. Do you feel neovim is off-topic for vim discussions? It seems fairly related to me.
> 1. async feature was proposed in 2014 and earlier, Bram was opposed to the idea in general
Not accepting a patch without question doesn't mean he was opposed to the idea.
I'm linking this[0] post, not to talk about why/if neovim is better than vim, but rather because it gives a nice overview of why that patch was rejected, and why neovim was started.
[0]http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...
Look at the linked mailing list thread. It wasn't rejected, there were several adjustments for coding conventions, naming, etc and the last thing Bram mentioned was basically "we'll consider it".
Then the developer threw a hissy fit a few days later and created a fork because his patch wasn't accepted right away.
> Then the developer threw a hissy fit a few days later and created a fork because his patch wasn't accepted right away.
According to the Geoff Greer, they didn't fork Vim. The fork happened a couple of months after their patch wasn't accepted, and they joined: "A couple of months after my disillusionment with Vim, Thiago de Arruda submitted a similar patch. It was likewise rejected. But unlike me, Thiago didn’t give up. He started NeoVim and created a Bountysource for it." http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...
I remember when that went down and I was sympathetic. It was a shit show and a total waste of their time. I would have been angry enough to start a competing project too.
He didn't accept several patches, did he?
post hoc, ergo propter hoc -- this is a logical fallacy
This would be a post hoc, ergo propter hoc fallacy:
1. async feature proposed and implemented in neovim
2. vim comes out with its own async feature.
shazow's post has significantly more evidence of neovim's responsibility, enough that it isn't a fallacious argument. It isn't definitive proof, either.
I understand that assisting AIDS sufferers in Uganda is a favorite cause of Bram Moolenaar. However in the absence of an overall plan to help the country develop, such short-term interventions may be a net harm to the very populations they're intended to help.
http://www.economist.com/news/middle-east-and-africa/2161334...
I would encourage folks to read up on factors surrounding the causes they support. Perhaps organizations like the Free Software Conservancy could use your donation to benefit humanity far more profoundly, even if they can't compete on emotional appeal.
I agree with the general point, and I believe it's well-established, that aid can have second-order and higher order effects that are counter-productive. On the other hand, in this case it's merely FUD and an argument for inaction; we would need specific information about Moolenaar's charity. I'm not going to stand still and do nothing just in case.
Second-order effects also can make donations to the Free Software Conservancy counter-productive.
As an aside, I wonder if the Free Software Conservancy would want to be seen telling people not to donate to Ugandan AIDS victims and to redirect the money to themselves. My guess is they would not like to see their name here.
> emotional appeal
Life and death has appeal beyond 'mere' emotion. It's more important than free software, and I say that as an avid fan of, and occasional donor and contributor to FOSS projects.
EDIT: A rewording or two
> I'm not going to stand still and do nothing
The advice "Don't just do something, stand there!" comes to mind.
Bram has been going to Kibaale since 1994, and he's now presumably busy feeding and clothing a new generation of orphaned children, orphaned by the original orphans. Isn't this precisely the creation of a trans-generational cycle of dependency by Western patrons?
Wouldn't those people rather be in a position to feed and clothe their own population? Perhaps even be the ones sending charitable aid workers to the Netherlands.
What is happening is evidently not a path to freedom and independence. The correct action can be found in inaction.
> Life and death has appeal beyond 'mere' emotion.
Remember it's true: lives are valuable, but our dignity is valuable too.
How do you know they're the children of children he's helped? Latest news posting underlines emphasis on education & getting people employed
I'm all for individual achievements, but I wouldn't call turning people into lawyers and Arsenal supporters an unequivocally positive outcome.
Should you feel moved to give to Bram's organization, at least consider an offsetting donation to help address the eradication of pristine savannah, extinctions from over-hunting, elimination of biodiversity, and other imbalances which will naturally occur when a human population is suddenly freed from all checks on growth.
https://en.wikipedia.org/wiki/Kibaale_District#Population
Or one might consider just making the world a better place by doing something we actually understand - like, writing software and doing our jobs, instead of staying up late $#!+posting ;-)
> he's now presumably busy feeding and clothing a new generation of orphaned children, orphaned by the original orphans
That comment makes up a fact and then criticizes it.
I have no idea what the outcomes are for the people Bram helped and I doubt you do, though I'm confident they have a little more food and whatever else he provides. There are still problems in Uganda and there are still problems everywhere in the world, including in rich nations, in your family and mine, in your life and mine; there are bugs in Linux' code. The fact that problems remain doesn't in any way imply that the efforts to improve are counter-productive. That doesn't make sense.
I don't even...
I just made a donation. Thanks for the nudge. :]
I am happy that at least one person got what I was meaning :)
Notable improvements:
- Async /Io
- Async Jobs
- "Packages", which allow easier built-in bundling of plugins
I'm pretty excited for this release! I've been using Neovim for several months now, but really great to see mainline Vim get these (IMO long overdue) enhancements.
lambdas and closure .. and vim/neovim split .. almost Emacs ;)
Soon NeoVim will no longer update regularly because Vim has caught up and/or surpassed it with every feature that matters...
By that time Emacs will have replaced temacs with Guile and someone clever will have added VimScript as a hosted language.
It's close, but I think NeoVim's RPC model could be huge. Writing a new frontend for vim no longer seems that crazy of a goal which makes it easier for people to experiment with new editor ideas while relying on the very solid core of vim (well at least I find that exciting, idk if the general vimmer cares).
I dream of the day that when you tick off "vim binding" in the settings of any IDE it loads neovim for controlling the buffer.
Or rather, a day where its easier, more flexible, and more performant for IDEs to always(only) use an embedded neovim. Getting plugin support "for free".
The keybindings would then be the only thing that the IDE changes.
I dream of the day when the IDE is in vim. There has been some great work around c# for this lately, where the compiler is running as a service and vim makes an async call for file completion, etc.
Why stop at the IDE? Why not tick a checkbox in system preferences and it lets you use vim to edit anywhere you can type text.
Now I would pay for that feature decent sum of money :D.
Are you familiar with Wasavi? Vi(m?) for browser text windows, at least.
The neovim project is still a massive undertaking about refactoring such old and non trivial piece of code in what appears to be a smooth way. I hope they can keep working on it, in symbiosis with vim.
I'd love to see vim add an embedded terminal emulator in a window based on the async support. That feature alone motivated me to try neovim.
That is tmux's job. Do one thing well.
I use ConqueTerm, inside vim, a plugin that supplies a terminal inside Vim. If you put the emulator inside the editor, you can take advantage of vim's extremely capable text manipulation. If I tmux then vim, I have to find some way to get the text out of tmux, and then back into vim.
Also, who says vim is running in a terminal?
Living inside the terminal, multiplexing is useful even when not using Vim and I think Tmux is a better multiplexer than Vim. I would need to use Tmux anyway for it's sessions.
I already use Tmux inside a tiling window manager and generally try to avoid manually managing panes inside Vim, mostly only tabs. There is a finite amount of hierarchical panes and tabs you can work with intuitively, before you wonder why they won't accept each others keyboard shortcuts, especially when you use the same color scheme in Vim, Tmux and Awesome.
> If I tmux then vim, I have to find some way to get the text out of tmux, and then back into vim.
That's actually a valid concern. I use piping for that, but it's not ideal at all. Maybe I will try it out.
> There is a finite amount of hierarchical panes and tabs you can work with intuitively, before you wonder why they won't accept each others keyboard shortcuts
Exactly the reason I want to manage terminals in vim. I already heavily use splitting in vim, and find it much faster and simpler to use than screen or tmux. In addition, I typically want integration between those splits, such as displaying the quickfix list in one, or showing 2-3 files in vimdiff, or yanking and pasting between files. Given that, I'd like to just open one more split in vim and have a terminal in it.
The original motivating use case for me: a vertical split, editing a manpage on one side, and showing a continuously updated render of the manpage on the other (using watch).
I was playing devils advocate a bit in the last post ;-) My workflow involves a mix of the two methods. If I know I'm going to be doing text manipulation, I'll use vim+ConqueTerm, but more normally I just let iTerm2's splitting handle it. (I actually prefer it over tmux/screen, but when you need multiple things on a remote, I can see why people prefer it.)
That feels like the realm of a plugin, IMO. (I don't know enough to know whether or not that type of thing could be done via plugin, though.)
With the new async support it should be relatively simple, weekend project simple for a basic implementation.
Depends on how you implement it. neovim's implementation uses libvterm, which seems preferable to a from-scratch terminal implementation. Implementing a fully capable terminal emulator from scratch definitely isn't a weekend project.
neovim's approach links libvterm in via C. You could potentially do so via python and ctypes instead, but then you have to count on having a vim compiled with Python support.
I was thinking I'd just start sh/cmd in a process and use stdin/stdout. The api even allows for automatically sending appended lines to stdin.
this async thing was Neovim's main selling point, right? I mean cruft-removal is all well and good but vim works fast and fine for me so not important. What does Neovim now offer that this doesn't?
Vim was in a virtual lock down of maintenance mode before Neovim came along and offered some competition. I'm happy to see Vim woken up out of its slumber, but let us not dismiss what Neovim offers or has already accomplished.
The release history: https://en.wikipedia.org/wiki/Vim_(text_editor) doesn't looks pretty active to me.
Edit - I mean does look pretty active.
I think neovim just offered us VIM 8.0.
To be fair VIM developers have said they were all in the mix and coming. We even had Vim plug ins that pulled this off. So I really am not surprised.
'transform Vim into an embeddable text editor engine'
I think that was the main objective of the project. Would be nice to real vim in IntelliJ idea.
As a naive IntelliJ user, I found myself editing files with Vim in IntelliJ's terminal console.
I was amazed when I discovered the console and everything works. I can launch vim, neovim and tig(nurses git front-end) from within IntelliJ and all shortcuts just work. Even fish shell in vi mode or tmux. So yeah, I have the shell running in IntelliJ with tmux enabled and launch tig inside of it.
whoa! had no idea this was thing .
This. And the scripting language I suppose?
Neovim is still a lot faster for me. A simple example is always commenting out a block <C-v>10jI#, which takes 5 seconds or so in vim (including 8.0), but is instant in neovim.
The input sequence would be <C-v>10jI#<ESC> (I've just added escape at the end).
I'm guessing the delay you are referring to is the delay imposed by your terminal emulator (not vim) to detect the Escape key at the end that terminates visual block mode. If I'm right, you can quickly press "j" just after you press ESC, which should cancel the ESC-detection delay and cause your comment characters to appear instantly.
Edit: there's actually a few things that could be at play, including your terminal emulator, your screen/tmux (which is like another terminal editor, really), and vim's timeoutlen and ttimeoutlen settings.
This is interesting! For me using <ESC> does indeed take a few seconds to complete commenting out the block. However, I have jk mapped to <ESC> and the commenting happens instantly using jk which makes sense in the context of your explanation.
It is interesting, I just tried pressing 'j' immediately after <esc> and the block prefixing does happen right when I press 'j'. The usual lag is just a second or two for me, though, using Gnome Terminal on Ubuntu. Also, there is no lag at all for me in gvim, even without pressing <esc>j.
I wouldn't expect the terminal emulator or screen/tmux to cause a 5s delay in this situation; and if they did, I'd expect them to cause it in neovim as well as in vim.
This does happen with neovim too. In fact, I had this issue in neovim even though I hadn't had it in vim. It was a one-line config change in my tmux.conf to fix it though, so no skin off my nose.
You can also add this to your .vimrc:
set noesckeysThis worked! Sweet! Maybe neovim just has this as default..
I'd recommend https://github.com/tpope/vim-commentary for commenting out code. Anyway, it's not a good practice.
What would you recommend for turning off a section of code temporarily?
For C:
#if 0 ...code... #endifYou could try a plugin I wrote to quickly comment/uncomment blocks of code:
https://github.com/Jaymon/vim-commentify
It's a no frills plugin that only does one thing, but it does it pretty well.
Kill region, save, run/compile/read, undo if needed. With undo tree (or if you add commit to the process above) there is no need to comment just one region to turn off something.
Optionally, convert the region into a separate function/method and just don't call it while checking.
You still didn't explained why it wasn't a good practice. This just sounds impractical.
Commented code (as in, working code commented out, not comments in code) eventually rots/becomes cruft that at some point in time is going to bite you (or someone else in your team, or some maintainer in the future)
Yeah, "not a good practice" (i.e. "the user is wrong" or "why would you want to do that?") is the lazy way of justifying software deficiencies.
I use emacs, so deficiencies on how vim handles anything do not mean much to me, actually.
I believe it has a complete embedded terminal
I've actually started using neovim as a default terminal paired with my standard shell. I personally never got that used to the commands for tmux or screen, and with neovim I get the exact commands I am expected as well as -send line to REPL- with https://github.com/kassio/neoterm
having lua as the native scripting language is pretty big too
Lula would be proud ;-)
How is Neovim working out for you? I remember using it at one point and it was really smooth experience.
I'm using it every day for a couple of months now, never crashed and loads faster than Vim 7.
Anyway, the things I appreciate more are the fast evolution and the community, no more than one year ago I tried it but was too lazy to compile, wait, configure...
This time I ran homebrew, linked my .vimrc in ~/.config/nvim/init.vim, and forgot I was using Neovim instead of Vim, except for the async compiling/linting.
I switched more than a year ago and have never had stability problems; it's been only performance and feature enhancements for me. The most obvious was that saving my files no longer locked up the interface for a couple seconds while linters ran (thank you async). More subtly, I had to go on a plugin diet initially that slimmed my features down to what I actually used regularly; since then, I judge the quality of plugins to be improved because they're either new plugins by authors excited to code for neovim, or they're current plugins that got a decent overhaul to work with both.
From what I understand, the plugin community is generally pretty happy with neovim and find it preferable.
Not the parent but FWIW I've been using neovim for +6 months now and it's fantastic. I'm super impressed at the pace of progress and responsiveness of the team.
I've since switched all my plugins to use async versions and it's sooo fast, didn't think vim could be faster but here we are.
Could you mention which plugins you switched to? Is there a list somewhere that details the alternatives that work better in neovim?
Off the top of my head:
- vim-plug for a plugin manager (very good regardless of concurrency)
- neomake for building
- vim-go added async job support using neovim a while ago for most of its functionality, which I use for writing Go
My full inventory is here: https://github.com/shazow/dotfiles/blob/master/.vim/plugins....
Do most vim plugins work without changes in neovim? I'm mostly using vim-airline and tagbar to be honest, wouldn't be sad if the other ones stopped working.
VimScript is not deprecated in NeoVim, and maintaining backward compatibility is major focus. So must Vim plugins will work in Neovim. vim-airline is listed among the plugins that has some special neovim-specific features added: https://github.com/neovim/neovim/wiki/Related-projects
Cool, thanks.
I've been using neovim for almost a year now, and have contributed some (small) code fixes and also donate to the project. It works great for me, and I completely forget that I'm using neovim (until I use :terminal). Also, from what I hear, contributing to Vim is much harder than NeoVim so I'm more inclined to contribute to a project which has a healthy community of contributors.
I am stuck at 0.1.3 as I am unable to brew install any of the newer versions. (It craps out on some LuaJIT stuff and I haven't really had time to fight with it) Aside from having to mess with it to get CTRL-h working, it's been pretty smooth. I LOVED vimplug (the package manager) with its async installs. I have high hopes for NeoVim's future... even if that future turns out to be just giving Vim a kick in the pants to move forward.
Try cleaning your Homebrew cache for neovim.
rm -rf /Library/Caches/Homebrew/neovim--git brew reinstall --HEAD neovimnope, sadly:
I know I just need to jump into figuring out how to get the ONE version of LuaJIT that works (as I've read, there is only one) and pop that in there.==> make VERBOSE=1 Last 15 lines from /Users/jimwharton/Library/Logs/Homebrew/neovim/02.make: "__Unwind_GetCFA", referenced from: _lj_err_unwind_dwarf in libluajit.a(lj_err.o) "__Unwind_RaiseException", referenced from: _lj_err_throw in libluajit.a(lj_err.o) "__Unwind_SetGR", referenced from: _lj_err_unwind_dwarf in libluajit.a(lj_err.o) "__Unwind_SetIP", referenced from: _lj_err_unwind_dwarf in libluajit.a(lj_err.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: *** [luajit] Error 1 make[3]: *** [src/luajit] Error 2 make[2]: *** [build/src/luajit-stamp/luajit-install] Error 2 make[1]: *** [CMakeFiles/luajit.dir/all] Error 2 make: *** [all] Error 2Try:
unset LUA_CPATH LUA_PATH brew reinstall --HEAD neovim
Really great! It was honestly a relatively painless transition for me.
I moved to http://wikemacs.org/wiki/Evil and I am happy with the transition. Spacemacs seems to be a good choice nowadays.
Magit and org-mode are worth it.
I would move to Spacemacs if it had the possibility for using a tabbed interface similar to GVim's. Ideally something already built in, mature, and one which wouldn't need any hand holding during operation.
Vim's tabbed interface is quite good, it's basically Vim + a Vim-specific stacking window manager.
There is such support in Spacemacs, it is called "spacemacs layouts" but the tab is visible only on demand while pressing `SPC l`. Eyebrowse is also integrated in Spacemacs layouts so you can have multiple sub-layouts for a given layouts. Note that Spacemacs layouts also achieve buffer isolation so you can have a layout restricted to project's buffers only, you can also create your own rules to automatically add buffers to some layouts (called custom layouts). Last you can persist Spacemacs layouts across sessions.
Layouts are fucking great. I have a moderately complex layout set up for my org-mode workflow (tasks list top left, agenda top center, notes file top right, kanban board bottom-left, and a scratch buffer bottom right), and they all load the same way every time. And I have project-specific layouts that get auto-loaded when I open that projectile project, and I have a general programming one as well. All of these took less than an hour to set up and work completely flawlessly.
I haven't used layouts much, but that sounds very useful.
Do you have your dotfiles somewhere online? Or could you put up the code needed for that setup in a gist/pastebin?
I don't have the dotfile up anywhere, but I can run you through the basics really quickly:
* SPC-l gives you the layouts micro-state, which allows you to do all of this. First, set up your layout however you'd like, then open up the micro-state and run the save-as command (SPC-l-S) and that will allow you to save the layout to a layouts file somewhere deep in the bowels of Spacemacs.
* When you're ready to use your layout, use SPC-l-L to load the layout from a file. Type its name (Helm is used, so you get narrowing/fuzzy-find for free) and the layout will load. Note that if you already had another layout loaded, it will load it to the next workspace (accessible through SPC-l-<workspace-number>).
* As for the org Kanban board, check here: http://www.draketo.de/light/english/free-software/el-kanban-... To add this to spacemacs, just open your .spacemacs file (SPC-f-e-d) and add `kanban` to your `dotspacemacs-additional-packages` list.
Spacemacs layouts are like having clippy in your text editor. "It looks like you're opening a tab, would you like to continue?", "What would you like to name this tab?". Vim just opens a tab.
There is vim-like tabs implementation for evil users: https://github.com/krisajenkins/evil-tabs .
I personally use emacs-native way, window-configuration-to-register: https://www.emacswiki.org/emacs/WindowsAndRegisters
(I see you've edited your comment meanwhile but I'll leave my comment here for reference)
I've seen some of these but I don't think any of them actually follow the tabbed interface paradigm:
* visible tab bar, preferably at the top and preferably style-able so that it doesn't look like it's out of Windows 3.11
* dynamic tab names based on file contents (in case of multiple buffers, show the name of the currently focused buffer), so that there's no need for manual tab name management
* tab navigation through shortcuts (open tab, close tab, move tab left/right, etc.)
Sorry for edit. I found and installed evil-tabs after replying and it's actually quite good.
It meets all the points you raised, and I agree with them - I prefer evil-tabs for that reason. Although I must that admit that evil-tabs only implements only crucial subset of all vim tabs features mentioned in http://vim.wikia.com/wiki/Using_tab_pages .
For future reference, evil-tabs is just skin over elscreen.
I created tmux-like keybindings, leveraging hydra and helm for some commands: https://gist.github.com/kozikow/58b46c45a2c24406dc7cde3f1861... .
In emacs, helm-buffer ("<SPC> b b" in spacemacs) has basically replaced tabs for me, and I haven't really missed them.
I tried that. Evil seems to mess up on things now and then. Clicking the mouse acts as a command or something, wiping out ".". And macros, now and then, act up. As in, they won't record properly or something. On large Rust files, things grind to a halt if I run a macro on every line, whereas in Vim proper, things always stay speedy.
In concept though, it is the best solution. Maybe I just have a broken config or something.
> And macros, now and then, act up. As in, they won't record properly or something.
What you may be experiencing is an erroneous action stopping the macro. For example, if you press h at the beginning of the line, macro recording would be stopped. To make this behaviour less annoying add: (setq evil-kbd-macro-suppress-motion-error t) .
Sublime-like multi-cursors in emacs are sometimes more useful than macros. I use and like https://github.com/gabesoft/evil-mc .
Regarding other points:
- yes, for huuuge files I still use vim - Occasional bugs due happen, as in every editor running custom plugins. In emacs debugging and editing plugins code is natural. You can use emacs to debug itself and reload parts of code without restarting.Hot damn that was probably it. Thanks!
> On large Rust files, things grind to a halt if I run a macro on every line
I actually started testing Spacemacs ad Vim was getting slow when highliting big .rs files.
Sublime + Vintageous for me.
More than anything, Vim for me is a really good set of keybindings.
I couldn't deal with Vintageous or Vintage. The lack of a proper ex-line for me kills it, along with spotty support for certain visual-mode movements. The rough edges are right at the forefront all the time when I try.
Many people feel that way too, that's why I started ex-mode[0] for Atom. If anyone cares, it could use contributors.
I love Vim keybindings - but for me they don't "work" outside Vim. I just keep using Vim's and Cua keybindings mixed together...
Did the same best of both worlds.
I'm a big fan of evil-mode as well, though for some things they can't decide if they want to be just like vim or not (One example is whether or not yanking to the default register goes to the clipboard).
For me yanking with `y` copies to my system clipboard. I'm pretty sure this has nothing to do with evil; I think it's an emacs setting. Perhaps one of these?
See https://www.gnu.org/software/emacs/manual/html_node/emacs/Cl...(setq select-enable-clipboard t) (setq select-enable-primary t)
I did the same. These advancements in vim are too little, too late for me.
I want to use org-mode as well so I tried the switch to evil/spacemacs, but slight differences in keybindings and behaviors between evil and vim were enough to turn me off.
Announcement here: https://groups.google.com/forum/#!topic/vim_announce/EKTuhjF...
Thanks for the work done here. I'm not a VIM user anymore (I use Spacemacs now), but it opened my eyes/mind to what is a professional code editor. After using VIM, using any other editor feels like programming in Notepad. VIM you'll always be in my heart.
I use Spacemacs for Elixir programming and honestly, Emacs is slow, I would often type commands and then wait for it to complete. I think some reboot like Neovim did for Vim, could be beneficial as it is awesome editor, but it is just too slow to start and slow to use.
It might be that Spacemacs layer is adding additional complexity, and maybe going through Helm is the issue, I don't know, just it does take quite a bit for it to catch up. In Vim, you really are plowing through at the speed of thought.
You should try profiling to see if anything comes out as taking up a lot of resources. `M-x profiler-start`, do some work or type some stuff (if you notice that it's slow), then do `M-x profiler-report` to see if anything in particular is slowing things down. Note though that the part where you type `M-x profiler-report` may sometimes show up in the profiler so ignore that.
See https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
It's true that emacs can get pretty slow if you have so many things running that you don't even need. It's also useful to defer packages until you actually need them by using autoloads or if you use use-package, `:defer/:commands/:bind` which create them for you.
Core Emacs is extremely snappy, slowdowns generally occur from packages. Helm is indeed a giant monster. Highlighting and redisplay is another area where things slow down.
I run on an eight year old Thinkpad. I run my own config now, but used Spacemacs for quite some time. I've never had problems with speed. I didn't use it with Elixir though.
Perhaps try disabling your layers one at a time to see where the problem is.
I don't think it is Elixir, it is Helm most likely as someone already mentioned. I am using Vim and Emacs and I do notice significant difference in response to commands.
Helm is super helpful, so most likely I will disable it and see how it goes.
You could try looking at using ivy instead of helm. Not tried it myself but there was a thread on the emacs reddit last week [1] where people said it's much faster.
speed is the main reason i'm not using spacemacs, it has problems just rendering it's own default config file when navigating around it (granted i'm stuck on windows at work which is far from optimal).
What did Neovim do for VIM? Vim was saying all these things were in the workds way before Neovim.
Might see in my tone I am not a fan of this fork.
How did you learn Spacemacs? I'm still using vim but would like to try & learn Spacemacs. What's a good way to learn it?
I just dove in about six months ago, and now I feel v productive in Spacemacs. The Spacemacs ABC videos are helpful.
Three of Spacemac's four pillars (mnemonic, discoverable, consistent) make it relatively easy to get the hang of. My early usage looked something like:
- Think of task I want to accomplish that probably has key binding
- Begin typing SPC - <continue drilling down through menus that look promising>
- If that doesn't work, type SPC-: and begin typing what I think the command might be called
- If that doesn't work, search web for "Spacemacs key binding <thing I want to do>"
- If that doesn't work, find/read relevant Spacemacs layer documentation
- If that doesn't work, ask in the Spacemacs gitter channel
- Memorize key binding
Once I learned a binding I found it easy to remember due to the mnemonicness:
open this file in Github? SPC-g-h-o of course (g (git) - h (..hub) - (open))
view most recent search buffer? SPC-s-l (s (search) - l (last search buffer))
maximize this window's buffer? SPC-w-m, etc
I have dabbled in spacemacs a tiny bit and I have been using vim for years. Basically I think there are two ways to learn spacemacs.
Method 1
1. Become proficient in vim
2. Become proficient in emacs
3. Learn spacemacs keyboard shortcuts
Method 2
1. Become proficient in emacs
2. Become proficient in vim
3. Learn spacemacs keyboard shortcuts
I'm a vim user, but I know almost nothing about emacs, so I am having a tough time adopting spacemacs. The basic editing features are a flawless reproduction of vim, but when I do `set textwidth=99` it doesn't work. Then I end up googling how to do this in spacemacs which is apparently `spc : set-fill-column <enter> 99`. This is just one example, but there are many others if you try to do anything different from the spacemacs defaults.
I have also been a Vim user for a decent while now. I try to minimize the number of plug-ins that I use, lest I get into the plugin circus.
To migrate to Spacemacs, I just replicated my workflow. Earlier I would use `find . ...` extensively for complex grep. I figured the equivalent in Spacemacs. For file navigation I used the NerdTree. I again looked up the key bindings for file navigation. So on, so forth. I now have a pretty decent spacemacs setup.
I would think, this can also classify as a third method, without having to become proficient in Emacs.
The documentation is very good. I recommend downloading and installing it and just playing around. Just press the spacebar and you'll see an organized, easily discoverable command interface pop up. Magit is very straightforward if you know how to use the git commandline. Type SPC g s (SPC git status) to open the magit on the current file, then ? to view the available commands. Although org-mode is a massive beast, it can still be productive to simply start by learning small parts and increase the set of features you use over time.
The whole thing should be fun, not just laborious.
http://spacemacs.org/ http://spacemacs.org/doc/QUICK_START.html
Besides the great documentation, watching "Spacemacs ABC" helped a lot: https://www.youtube.com/playlist?list=PLrJ2YN5y27KLhd3yNs2dR...
I've used vim, pretty heavily customized, for almost a decade now. It seems to me perfect, and if not perfect, I just change it so it's perfect.
I've been using pathogen for a while for plugins..
I will happily give 8.0 a try, but I have never used such perfect software such as vim (and I also don't follow its dev cycle at all) I am really, really surprised a new version came out. I figured I'd be using the same vim until keyboards were completely out of style.
Is there feature/API parity between Vim 8 and NeoVim? I would hate to see the community fragment and disintegrate.
The main devs of NeoVim offered to work out an api for both versions but it never happend.
Seems like we are now in a feature war between both lets see who comes out winning. This whole thing could have happend so much smoother for the community but stubbornness sometimes lead to interesting innovations :).
If anyone is curious, here is the thread in question where the vim async API was proposed and the neovim devs proposed collaboration and were shut down without actually looking at the details:
https://groups.google.com/forum/#!topic/vim_dev/_SbMTGshzVc/...
Some choice posts:
- Bram (vim author's) response to whether he looked at existing implementation in neovim: https://groups.google.com/d/msg/vim_dev/_SbMTGshzVc/wXmJuL4P...
- Thiago (neovim author's) response to Bram, which was ignored: https://groups.google.com/d/msg/vim_dev/_SbMTGshzVc/XZEXxaxD...
There are lots of other instances of this exact interaction between neovim and vim over and over, it's infuriating. Neovim was started precisely for this reason, an async proposal was made (in 2014!!) which was rudely shut down and all efforts of collaboration were ignored.
I'm sorry, but Thiago's response is clearly patronising. Giving Bram advice on how to "properly" implement channels and job control. Suggesting taking the old infamous old patch.
I got pissed off for Bram reading it.
Also Bram had much more detailed and valid criticism about neovim's implementation above the response you linked. Did you intentionally link that one to make Bram look bad or did you simply not read the whole thread? I'm betting on the former.
Thiago's response comes from several years of experience actually doing and having done what Bram what proposing: first creating the async path for vim, fighting for its acceptance, then forking vim, implementing it, and shepherding it as the key feature of neovim. So far, I've heard no major complaints about neovim's async; it's actually been the killer feature so far.
Bram might be the more experienced programmer overall, but for implementing async in vim, I'll take Thiago's learned opinion over Bram's 'the horse has been dragged to water' solution anyday.
I wasn't talking about Thiago's credentials. I was talking about the tone in his reply which was clearly abrasive.
Brams criticism is valid about Thiago solution. Forcing msgpack is less than ideal. It's clear Thiago is learning as he goes along. Taking his work without reflection would be silly.
Also it is also clear neovim wants plugin writers. So they want vim to be compatible with what they made so they can grab users.
Why should vim care about being compatible with neovim?
I don't agree with your reading of Thiago's tone--you found it patronising, I found it trying hard to be polite to Bram, who's being the same dismissive senior dev he was when he rejected Thiago's first and second attempts at patches to do what was done very well in neovim.
As for why vim should care? Because at this point I'd put money on neovim as the long term winner, and if I were Bram, I'd worry about vim joining vi on the sidelines as 'still developed, still in use, but not the vi everyone uses when they log into a linux box'. I'd look at my codebase and neovim's, at my toolchain and neovim's, at my community and neovim's, at my velocity and neovim's, and I'd imagine neovim eclipsing vim over time.
Maybe that's fine. But Bram is hardly some god-king who's position as foremost developer in the vi universe is a lifetime appointment--especially after he took that position from Bill Joy.
Why are you on the side of someone who has a hard time being polite. I read the original threads about Thiagos original patch and he was in the wrong. He ignored issues that were outlined and it was clear the patch was not ready. He was not polite.
Once again Bram brings up a valid issue with neovims design about using msgpack for RPC. It just adds another layer of difficulty.
So explain to me why vim should include such an obviously flawed design?
By "trying hard to be polite", I mean he was making an effort to be polite when he had no need to be after Bram was already rude and dismissive, not that Thiago has trouble being polite. Read the neovim issues in github: Thiago is a model of good-natured engagement with almost everyone. In the original patch request thread he's far from impolite, and he's more polite than Bram is.
And "makes debugging difficult" is an observation, not a criticism or valid reason to reject--it's certainly not detailed, as you said. Yes, it's more difficult debugging it directly, but the architectural separation makes the components more loosely coupled and more easily tested in isolation--it's a valid tradeoff, and one the neovim has demonstrated to work well in actual fact.
I mean, it's an accomplishment for Bram to add async to vim, but let's not forget who actually did it first, successfully, and along the way accomplished a lot more.
Why are you so hostile to neovim? By any measure they've done a tremendous job modernizing the codebase for vim and rejuvenating development of both neovim and vim.
Step back and ask yourself: if you were approaching both projects fresh, and asking which you might want to participate in, which would you choose and why, ignoring politeness on either side?
This is what is now possible with Neovim: https://www.youtube.com/watch?v=TI5azVeDUDo
Neovim already fragmented the community. Bram seems to have stepped up to the challenge bigtime since neovim announcement, as judged by his github activity graph.
This is misleading. Bram takes commit ownership of external contributors. Compare it to Neovim, which feels much more like a community: https://github.com/neovim/neovim/graphs/contributors
Also see the changelog messages in vim, and compare them to the changelog messages in neovim.
that was true pre-neovim too so we still can say that activity has increased signficantly post-neovim announcement.
I wouldn't say he's stepped up. It's all a reactionary response to Neovim. I dont think we'd ever have async in vim if it weren't for the neovim project.
That being said I hope they pull an io.js and merge taking the best of both vim and neovim, whatever that may be.
"Stepped up to challenge" is a reactionary response.
Something challenges you, your reaction is to ignore/quit or step up and respond.
you know what? I'm prepared to cut Bram Moolenaar a lot of slack given the goodness he gave us for 20 years through 7 versions of one of my top 3 pieces of useful software.
he's a great guy but at some point it's time to move on
Downvotes for speaking the truth and adding to the discussion. Thanks guys.
but move on from what exactly? Vim 8? Looks good to me....
Maybe you want to move on just for the sake of moving on? To a new generation? Can you explain why? Seems to me that the person who knows the code base 200%, who wrote/vetted the entire codebase, is better placed to add features, than newbie refactorers who didn't?
Those newbie refactorers took a 300k line codebase, removed 130k lines of cruft, got it working on a modern toolchain, created an actual OSS dev community without a bus factor of 1, and added two major new features (async and embedded terminal) of which vim has only gotten around to adding 1, while improving performance and laying the groundwork for another major new feature (embeddable) that vim will take years to catch up to.
And all of that while maintaining such good backwards compatibility that almost all vim plugins work unmodified. Plugin authors only need to lift a finger to take advantage of new capabilities like async.
I didn't switch just for the sake of moving on. I switched because by any appreciable aspect, neovim and the developers behind it are simply better than vim.
Thank you for elaborating on my point. Very well said.
While this may sometimes be true, it would be dishonest to claim that only the original author of a project should be allowed to maintain it. It's also incorrect, since distributions all maintain forks of vim as well. Given how much time and effort the NeoVim community has put into improving the state of vim (that includes refactoring, as well as much more significant features you ignored like async which NeoVim had first since the maintainer of Vim didn't want async), it is quite disrespectful to call them "newbie refactorers". Everything I've seen of the vim development community makes me feel that it is quite toxic, so I'm very happy with the more open development model that NeoVim has.
neovim will most likely merge good features from vim 8, but I find unlikely that the opposite happens. To be fair, I'm actually okay with that. One of the reasons neovim is where it is right now is because they forked it and because they keep it forked. I'm not sure how fast it would improve if neovim merged back.
can't imagine that happening unless vim drops some platforms it supports.
Well, at this point in time Amiga and MS DOS should probably go.
They're served decently enough by older versions and I doubt that any machine running those has the resources for features provided by newer Vim versions. Even if they do, the OS support for these features might not be good enough.
He did drop some platforms, although nowhere near as many as NeoVim did:
Omitted in this version are:
The 16-bit DOS, OS/2 and Amiga versions, these are obsolete.
The 32-bit console version for MS-DOS/Windows 95/98
The 16 bit MS-Windows version
async VIM - We had it 4 years ago with VIM-Dispatch.
If you know how vim-dispatch works, you'll know that it just opens up a split in Tmux/Screen or makes a new tab/window in your terminal emulator to run the command "asynchronously." While it does work, it's definitely a hack and not a feature of Vim.
Correction: Tim Pope managed to hack in a mostly-functional version 4 years ago.
Correction I linked Tim Pope's github page.
That never worked on windows.
You right about that I forgot.
Right. Frankly that's a disappointing response. One source software shouldn't be a competition. I'm still holding out for some kind of grand unification in the future. I'm sure this is becoming a nightmare for plug-in maintainers, because it's certainly a pain in the ass for users like me.
I submit my Vim Primer for your consideration.
https://danielmiessler.com/study/vim/
Going to download and see what Prezto stuff breaks when I upgrade.
Many thanks for this. I went through the whole tutorial and it was great.
Bram will give a talk about Vim 8.0 on Saturday at Vimfest in Berlin. I'm looking forward to be there.
From what I gather from the IRC discussion there will be no life stream but the talks will be recorded.
I moved to nvi. Feels good to go back a notch and realise that you actually don't need all of the other stuff to produce quality code.
Me, I just wrote my own editor that works exactly the way that I want it to work.
Every Jedi needs to build their own light saber, and come on, it's just 6KLOC or so.
Me, I wrote my own OS.
Every real Jedi needs to build their own light saber, and come on, it's just 100KLOC or so.
Link a repo, I'd love to check it out.
I've never even considered what goes into making an editor.
Not OP but https://github.com/pklausler/aoeui
ah! amazing, can i try it ?
I feel the same about 'vis'. Its lightening fast and does what I need.
I apologize if this is not the right place to ask but how would I go about adding the following vim/nvim functionality to .visrc.lua ?
inoremap jk <Esc> inoremap kj <Esc>
This is a great project, I'm keeping a really close eye on it, but still missing the few plugins I use in vim/neovim.
vis looks really interesting. i keep meaning to make the time to try it out properly
This is pretty rad. I've used Neovim for a few months now, but I always wanted to keep using the "official" editor due to it's support on pretty much every OS.
Async is basically the reason I used NeoVim, so it feels good to come back.
Here is the md5 checksum for the Windows binary (it's not shown on the website): 2ea0e00657f0cabf2f314b8a8f794271
Windows: ftp//ftp.vim.org/pub/vim/pc/gvim80.exe
MD5SUMS: ftp://ftp.vim.org/pub/vim/pc/MD5SUMS
I've tried nvim, sublime's vintage mode, atom's vim mode, visual code's vim mode, jet brains' vim mode, spacemacs and always end up going back to vim. I know it's far from being perfect. All of those other alternatives have features I wish vim had but at the end there's just no comparison against the flow you can get with something like tmux/vim/plugins
anyway to get this on osx now
Readme seems incomplete
https://github.com/vim/vim/blob/master/READMEdir/README_mac....
Eh..I'll probably wait a little bit longer.cd /usr/local/Cellar/vim/HEAD/share/vim/vim80/compiler; chmod 644 *.vim README.txt -bash: cd: /usr/local/Cellar/vim/HEAD/share/vim/vim80/compiler: No such file or directory chmod: *.vim: No such file or directory chmod: README.txt: No such file or directoryJust in case - I should probably have said "It's simply a case of $ brew update && brew install --HEAD vim".
It's happily just compiled and installed for me.
or update
$ brew update && brew upgrade vim --HEAD
Former OSX user here: Another vote for using vim out of brew. Brew + iterm2 was the only thing that kept me on OSX for so long due to just how inane OSX is as a unix environment.
I've since put Windows 10 on my MBPr (performs so much goddamned faster, Ivy Bridge era /w Intel GPU only, 8gb of RAM, decentish SSD for that generation), and use msys2 to fill that gap.
Disclaimer: My company Exelion hosts the msys2 mirror because their project is so important to the Windows community, and Sourceforge was having serious issues at the time. Well worth spending a dedi on them to keep the project going, imo.
MacVim is now using Vim 8.0
I didn't see anything in the release notes but does anyone know if Vim 8 adds true colour terminal support?
(I realise that NeoVim has this.)
I haven't searched for vim 8 specifically. But starting with vim v7.4.1770 there was a `set guicolors` option.
Update: Looking at the version8.txt[1] on github, the option seems to be `set termguicolors`
Change seemed to take place at version 7.4.1799[2]
[1]https://github.com/vim/vim/blob/master/runtime/doc/version8....
[2]https://github.com/vim/vim/blob/master/runtime/doc/version8....
Patch 7.4.1770
Problem: Cannot use true color in the terminal. Solution: Add the 'guicolors' option. (Nikolai Pavlov) Files: runtime/doc/options.txt, runtime/doc/term.txt, runtime/doc/various.txt, src/auto/configure, src/config.h.in, src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c, src/option.c, src/option.h, src/proto/term.pro, src/screen.c, src/structs.h, src/syntax.c, src/term.c, src/term.h, src/version.c, src/vim.hI just tried to get some information on this and all I found was info on how to enable this for NeoVIM.
The biggest power of vi for me is about it running on pretty much anything. If it has a keyboard and a screen, it has vi.
While I usually stick to I, A, N+G, Shitf-ZZ and :q! only, I appreciate the effort and keeping vi alive and well.
Big thanks!
Here's a useful one:
cnoremap sudow w !sudo tee % >/dev/null
Or from inside your editing session:
:w !sudo tee % > /dev/null
For when you find you've edited a file you don't own (e.g. config file) and forgot to sudo first.
Do yourself a favor and try some plugins. They're awesome.
Looks like there's a new :smile command
Neovim for life. On my Mac it performs so much better than Macvim.
I use tmux + vim on my Macbook and it runs really well! (vim built from MacPorts).
Have you tried tmux + neovim yet though? It's way faster and smoother in just about every aspect I can think of. Strongly recommend it.
I haven't but I've never had vim perform anything slower than perceptively instant. Even on the lowest of specification virtual machines and servers I've installed it on.
I'm not sure how, in my use case, neovim could improve upon vim. vim's fast, available virtually everywhere, packaged with many OS's and distros, and has a rich and active community. I'm not sure why I'd want to change.
Neovim seems like a fun project ("let's reimplement vim!") but it feels a bit redundant, like a reimplementation for the sake of doing a reimplementation. There's an intangible reason why vim is so popular and has such a following. vim is well engineered, simple, and has been well cared for over the years. If I'm integrating something so deeply into my workflow, electing it the main way I interface with my code, it's going to be the 25 year old project that's beyond reliable, has evolved conservatively and is ubiquitous. Ten years ago I was writing code in the language du jour using vim, and ten years from now I'll be working with the hot new language. In vim.
vim isn't a broken relic of the 90's, it's one of the best, most valuable tools in my toolbox.
Respectfully, given what you've said, you should look at neovim. It's not a fun project to reimplement vim, it's a fork due to vim's (i.e., Bram's) previous reluctance to advance vim with new features like async.
Since they've forked it, they've done an amazing job cleaning up the codebase, modernizing the toolchain and implementing great async support, while maintaining almost perfect compatibility with vim. They've also created a real development community where many people participate equally, not just trying to get the "bus factor of 1" commit bit holder to accept their patches.
I switched a year ago, brought all my plugins with me, and have seen only improvements in performance and features. If I had to choose which would survive for the next 30 years, it would be neovim. Thiego Arruda is the best example of an open source leader. I have a deep respect for Bram Moolenar and what he did with vim, but until neovim came along, vim was sclerotic and getting worse. It speaks well of Bram that when real competition came along, he returned to active development of vim.
Neovim is just vim improved, like vim is vi improved. It's a fork. Nobody is saying vim is a broken relic of the 90's. It is by far the most valuable tool in my box as well. The community is the same, plus some dedicated diligent people who want to improve the best editor in the world. Give it a shot!
Do you use a GUI or just the terminal?
Both. The nvim GUI is fluid and beautiful.
Great! I've been using neovim for the last year and it is pretty awesome. Hope 8.0 bring similar improvements to Vim as well. Hopefully, they'll merge back some day but even if they don't, I think neovim is here to stay. It has had amazing progress and so many contributions.
Kudos for finally getting async support! :)
That said, I feel like this is a perfect example showing off that the best way (or a at least a very good one) out of stagnation of a piece of software is competition. VIM was dead in the water for a very long time (aync support looking at you), which is but one of the reasons NeoVIM was created, in turn sparking VIM to actually get off its laurels.
I can't help but draw parallels to the Haskell community with stack and cabal-install, to the people that might be familiar with that situation.
Anyhow, I guess I just wanted to also thank NeoVIM for pushing some life into VIM again, besides having it more or less in maintenance mode.
I made the terrible error of trying to use vim as an IDE when I was learning to program. Honestly I think it set my progress back 75%.
Don't get me wrong, I use vim all the time cause it's there on any machine I log in to, but I found I was MUCH more productive when I paid for a good IDE for development.
And YES I tried using all the plugins to make vim into an IDE. That was half the problem.
Just gave neovim a try, and my favorite thing so far is that this command works (but does not with vim and has always bothered me)
$ find foo | xargs nvim
I thought find foo | xargs vim - did the trick?
In case you were looking for the Changelog: https://raw.githubusercontent.com/vim/vim/master/runtime/doc...
Finally a "Save to Dropbox" feature!
Does this new features means that vim can finally have lisp REPLs a la emacs?
I created docker image.
docker run -it -e TERM=screen-256color yaasita/vim:8.0 vim
Ok, and when would be for Cygwin ?
You don't have GCC on your cygwin install?
you can find the release notes here: http://vimhelp.appspot.com/version8.txt.html
Thanks, we updated the link from https://github.com/vim/vim/releases/tag/v8.0.0000.
Looks like their server is over quota. Here's the cached version -- http://webcache.googleusercontent.com/search?q=cache:DsKW591...
That page is now unavailable :)
Maybe https://github.com/vim/vim/blob/v8.0.0002/runtime/doc/versio... ?
Maybe not the best idea, the new link now shows:
> Over Quota
> This application is temporarily over its serving quota. Please try again later.
the linked appspot site is 503 over-quota. anyone can change the url to
https://groups.google.com/forum/#!topic/vim_dev/LaYdHDNzJcU
or
Thanks, we updated the link again.
Oh Vim...
If you're going to lightweight and vi-like, than do that. If you're going to go the Emacs route (and if you're adding async, packaging, and lambdas, make no mistake, you're starting in the steps to building an inferior Emacs), than get a half-decent extension language. Or just up and die. We don't need a Vi clone that does the Emacs thing, we've got Evil/Spacemacs for that.
The thing is, having tried Evil/Spacemacs, they're still really Emacs not Vim.
At some point you have drop out of the pseudo Vim world do things the Emacs way, keybindings and all.
For me personally, that's not what I want.
e.g. I like to use C-h as an alternative to backspace, it helps relieves my RSA not have to reach for backspace. Spacemacs provides that binding in some places but not all.
To get get C-h to consistently act as backspace I ended up effectively breaking the help system (which for an Emacs newbie like me is a bad thing).
I found loads of other things like that where I just want it to work the Vim way.
What I _really_ want is a better Vim not another editor pretending to be Vim on a superficial level. I'm glad to have the options that both Vim 8 and NeoVim offer.
Of course Emacs is an amazing bit of software and Spacemacs is a great configuration so if they work for you, more power to you.
> At some point you have drop out of the pseudo Vim world do things the Emacs way, keybindings and all.
or many packages there are many "vim-optimized" packages nowadays, e.g. evil-ediff, evil-org or evil-magit.
> e.g. I like to use C-h as an alternative to backspace, it helps relieves my RSA not have to reach for backspace.
I would do such remapping on the system level. E.g. I personally have my layout implemented in C++ on system level: https://github.com/kozikow/keyremaplinux
> I found loads of other things like that where I just want it to work the Vim way.
In Emacs in general it's easier to customise to do things your way. After a bit investment into learning elisp you can make it work however you want, including vim way. vim is not as customisable.
Yeah I'm pretty sure Emacs can be made to do anything.
I love that idea and I keep telling myself I'll go back and give give it another try sometime. Would love to get really into org-mode, etc.
It's just that Vim is so comfortable! ...like a nice old pair of Goodyear welted shoes.
As much as I've been complaining about Vim in this thread, I don't think it's evil, or anything. But I do love Emaca as much as you love Vi, for much the same reasons (although some of those one character commands make me envious). You could always use both (the non-religious option).
Come to the dark side. We have macros.
OK I'll make you a deal, as soon as I've mastered every feature in Vim I'll move on to Emacs. :)
Which reminds me, I must reread that stackoverflow post about grokking vi again.
http://stackoverflow.com/questions/1218390/what-is-your-most...
That's an incredibly useful post.
Anyways, I only suggested it because you seemed interested. There's certainly no requirement to do so. And since you'll never master every feature in Vim, you'll never use Emacs if you have that requirement.
The sad thing about Vi is its Lisp mode: the original Vi had a pretty nice mode for editing Lisp, which most clones have not recreated.
> or many packages there are many "vim-optimized" packages nowadays, e.g. evil-ediff, evil-org or evil-magit.
Sure, they come with bindings, but what about my custom bindings? Working with HJKL does not mean they are vim optimized.
That's certainly a way of thinking about things.
I guess what I really want is for Vim to decide what it wants to be. You can be simple, or you can be extensible. Vim is kind of trying to be both. Traditionally, Emacs did extensible, and Vi did simple. It's fine if Vim wants to go the emacs route, it's just that I'd rather it stopped doing it so badly: At this point, Vim's extensibility story is embarrassing. It's 2016, the built-in language is rubbish, the external language interfaces are second-class at best. This has to change if Vim really wants to go in that direction. And if doesn't, why bother pretending?
I don't want to discard your opinion but it does seem like a bit of a false dichotomy when we're talking about FOSS software.
No one is compelled to use Vim over Vi, you can just leave it in compatible mode or use another vi binary such as the one in busybox.
As far as the built in language and external API being second-class well you may have a point but both Vim and NeoVim are improving.
Whilst it's still useful and still provides, IMHO, nice ergonomics I'm probably going to stick with either Vim or NeoVim I think. I really don't mind if they never make up their mind what they want to be when they grow up. ;)
That's a respectable opinion.
From my perspective, I want to see Vim/NeoVim differentiating itself from the competition. It's extensible... but emacs does that better. It's simple and modal... but nvi does that better. It's stuck somewhere in the middle, and mediocrity is a terrible, terrible fate.
Ow! Stop that! Okay, this is the last time I sneak a Dresden Files quote into my HN comments. I swear. :-D.
> Or just up and die
Why would you bash VIM by saying it should die? Just move over to something else and use the "Mom Rule."
I was observing that with this new update, VIM is increasingly becoming an inferior Emacs. I argue that it should either die, because Emacs does what it's trying to do better, or distinguish itself in the editor space, like other Vi clones, by emphasizing simplicity over extreme flexibility.