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. :)
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.
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.
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 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.
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.
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.
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.
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.
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#.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- "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.
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).
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.
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 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.
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.)
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.
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.
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.
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.
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.
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)
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
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.
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
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.
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 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>).
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.
(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 .
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) .
- 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.
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.
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?
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.
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.
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).
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))
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.
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.
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:
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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 directory
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.
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!
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.
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.
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.
> 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.
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).
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.
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. ;)
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.
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.
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 :)