SpaceVim is a modular Vim distribution. but it has same idea with spacemacs. the goal of SpaceVim is to make user get a better experience of vim/neovim.
it's emacs with vim controls. FWIW, I wouldn't compare emacs with vim in this set up, but with something like tumx instead (and imo what emacs offers is better than tmux).
All these "distrobutions" are going to do is further fragment the already extremely confusing terminal-text-editor world. There are so many configurations that it's never going to make sense to me.
If it was simple, there'd be an answer to this question: how do I setup Vim/Emacs as a fully feature complete IDE for C, C++, Rust, Go, Java, JavaScript (Node or Web), C#?
By feature complete I mean autocomplete, error detection, built in one-button-runs, automatic config/sane defaults.
Keep in mind this is a dream list. It's perfectly fine if the list only includes 2-4 of these languages but it needs to have all of these features.
Looking at this from the outside (people who use IDEs) in (onto the people who use Vim/Emacs) we have maybe 1 IDE/Language and that's confusing for us. I can't imaginge having 3 text editors all of which have different common dotfiles.
> If it was simple, there'd be an answer to this question: how do I setup Vim/Emacs as a fully feature complete IDE for C, C++, Rust, Go, Java, JavaScript (Node or Web), C#?
That's the promise of Spacemacs:
- clone their git repository into your .emacs.d directory
- run emacs once, answer three basic questions about your preferences
- add your list of languages to the "dotspacemacs-configuration-layers" list in your .spacemacs
- I even looked up the syntax for you: "c-c++ rust go java javascript csharp"
- make it reload the config
You're done. All this should take less time than it took me to look up those "layer" names in the docs.
> By feature complete I mean autocomplete, error detection, built in one-button-runs, automatic config/sane defaults.
Yes, all that is the promise of Spacemacs.
If anything, I found it to be too much of a kitchen sink (it tries too hard to be "smart" about balancing parentheses for me etc.). Still, you might want to give it a whirl if you have 15 minutes. I ended up going back to vim for almost everything, and I'm on the line on whether to use Proof General from plain Emacs or from Spacemacs. But the time to check it out is not wasted.
Personally I'm thrilled by the fragmentation in this space -- I've been using Vim since 4.x, and vi before that. I've never found the plugins particularly enticing; every time I try using things that are outside the core distribution, they end up taking more time to maintain than they're worth. Since I mainly stick with the core distribution, Vim has felt pretty stagnant since it got code folding and syntax highlighting, more than 15 years ago. I've been trying alternatives -- spacemacs feels bloated, neovim is still carrying a lot of baggage (e.g. support for vimscript). So far Kakoune is the one I'm most excited about, to the point where I am right now updating my neglected Cygwin installation so I can try to build it for Windows. (Kakoune needs unix-style select, so native Windows builds are unlikely.)
> By feature complete I mean autocomplete, error detection, built in one-button-runs, automatic config/sane defaults.
By and large, I find features like these distracting to the point of unusability, which is why I like living in stripped-down editor land. Different strokes for different folks.
There is a learning curve, but at least with MELPA setting up Emacs is pretty easy. Company is a good autocomplete backend, Irony is a good back end for C/C++, and Company-Go and Emacs-Racer will do you for Go and Rust. Each of these can be installed by using interactive commands (M-x package-install), and configured with a few lines in your init.el (almost entirely just copying and pasting from the Github front page of the respective package).
I like the fragmentation, because different people have different needs. E.g. I prefer a much more minimalistic setup than my colleagues who use IDEs like Eclipse. I've never been able to comfortably use an IDE. And not a single vim config I found on the internet was right for me.
That said, I think many would agree that for C/C++ YouCompleteMe is a must-have. It has ctags functionality (but without false positives), error detection, autocomplete... And probably lots of other features I'm ignorant of.
There is a semi-official vim plugin for go. I used to use it when I was playing with this language. Same for Rust. I don't know about other languages you've mentioned.
As for the "distributions". I prefer to configure everything myself, but I get it that others might want everything preconfigured for them.
PS. Yes, I'd agree that vim has insane defaults. All vim config files I saw have a common part, I think.
This is generally what roadblocks me when I try to pick up vim. The part I hate about atom is reaching for my mouse. But I like that I didn't have to sacrifice my firstborn to get a sane setup for three langauege simultaneously.
I started using Spacemacs recently for its out-of-the-box IDE-like features but the layers' functionality seems to be fairly hit-or-miss and overall the impression is one of a bug-infested nightmare. Every time I try to set up my environment on a new machine, I get some new set of problems that I have no idea how to solve (disappearing powerline, broken neotree, weird projectile caching behavior totally breaking my workflow, busted syntax checking, and more). I don't blame the Spacemacs folks for this; I actually think what they've done is really cool. Emacs simply is what it is, I think. I don't have time nor inclination to learn elisp and build/fix my own environment.
When it does work, it's great. But the inconsistency is probably going to drive me away, back to Vim. I think that if anyone can build a similar thing for Vim that actually works, I'll use it in a heartbeat.
I have the exact opposite experience with vanilla Emacs. It works consistently without issue.
Regarding plugins you can use melpa and track the latest release of everything at all times.
You can use melpa and update most stuff infrequently save for the ones that are most important to you.
You can use melpa stable and run only stable versions of everything.
You can use melpa stable and run newer versions of a minority of plugins that are important to you.
What plugins you choose to use and and whether you choose stable or unstable could very well lead to vastly different experiences.
The best strategy is to carefully select plugins which are useful to you and high quality, and run the stable versions of most things updating your tools infrequently when a new major release adds something that looks useful to you.
There's a lot of factors here; were you on dev or master? What I suggest doing is using dev, but pinning yourself to a particular commit. Once you see that things are working, using that commit across all your machines. You can have a fork that you never push to, except to fast forward when you feel like upgrading. Just pull from that fork on new machines instead of from the main repo.
The only other thing that can break you other than updating spacemacs is updating packages, but that's a factor with vanilla emacs and with vim. This happens occasionally but not too often.
Also keep in mind: spacemacs is not all or nothing. There are many, many layers that are higher in the dependency tree, that both get less attention and are easier to swap. For instance, even though I mostly develop in C++, I don't use the C/C++ layer from spacemacs. There were things I wanted that were missing (like rtags), and things that I didn't want that were there (like older tags solutions).
I started out by just configuring rtags inside a single simple file, the same way a vanilla emacs user would, and I dropped the C++ layer. I eventually added more stuff and wrote my own C++ layer. I'm quite happy with the result. I still got a ton of useful layers/packages from spacemacs that were easily setup and configured, like evil, magit, helm, company, flycheck, etc. And the whole layer system itself made even the parts that I customized myself more modular.
That's a general problem with many 'frameworks'. When something goes off the happy path, the abstraction is gone and the user is dealing with the underlying abstractions. Elisp for Spacemacs; JavaScript for the hotness of the month, and X11 for Ubuntu.
I don't think it's really possible to build something like Spacemacs for Vim because of the different underlying architectural decisions. Vim is a one-thing-only-and-do-it-well tool. Emacs is 'an operating system missing a decent text edtior'.
I had the same experience with spacemacs, but it made me realize what I was missing with vim. Currently trying to build up an emacs/evil config from scratch.
I don't get Spacemacs hype. I tried it, and never felt comfortable using it. Started with blank .emacs.d, yeah I completely cleard whole configuration two or three times until I hit sweetspot. Now I'm sitting on ~250 loc config on vanilla emacs (including evil), and eveything works like a charm. Plus I learned a lot about elisp. I never liked those bundles and distributions. They always felt redundant, but I can understand the appeal to some people.
Yay for the effort! But personally I don't think this is a good way to learn and use vim. The strength of vim is to customise it after your own needs and you'll do yourself a disservice if you end up with a config that you don't know and don't use more than x percent of.
This is one of the most obtuse project descriptions I've seen. If you're making a...whatever this is...aimed at Vim users, why would you expect them to be familiar with a something-or-other for Emacs?
… and people wonder why I dislike Markdown. (There are fairly radical rendering differences between the GitHub page and the spacevim.org page, because different Markdown renderers with different bugs have been used, and the Markdown was fairly sloppily written.)
Yes I recognized the markdown fails from my own markdown fails. Especially when you move repos between github and bitbucket, and expect README.md to 'just work', it seldom does. I've gone between md, org and even rst. They are all great, but still suck in curious ways. pandoc helps but it is a whole kettle of fermented fish in itself.
The table rendering issues I suspect are from the lack of a newline after the headers. I don't know whether it's correct or not because, yknow, markdown.
Tried Spacemacs 3-4 times because of org mode. Most specifically inline code block execution, through org-babel. Still not ready to change over from vim, though.
What I haven't done is check neovim. Any comments regarding the potential for inline code execution?
Org-mode comes standard with plain emacs (no need for all the extra bells and whistles that come with spacemacs, necessarily). Since you're a vim user, try installing evil as a first plugin, and only adding additional ones as you see fit. I found that spacemacs did too much and preferred vanilla emacs + evil + a few python plugins. Still, I mostly use vim for smaller scripts. Emacs is better as an IDE in my opinion.
In my experience, you really can't beat Org-mode when it comes to inline code execution. You can preview LaTex and plotting inline as well. Plus, you can of course export the document into a variety of formats (HTML, PDF, etc.), which are quite customizable thereafter. Here is a document I put together with Org-mode for a short C++ seminar [1]. All the code is executable while editing the document in Org, which is nice for a number of reasons. I also added some custom CSS/JS for the HTML export.
vim sh mv ~/.vimrc ~/.vimrc_bak mv ~/.vim ~/.vim_bak git clone https://github.com/SpaceVim/SpaceVim.git ~/.vim
nvim sh git clone https://github.com/SpaceVim/SpaceVim.git ~/.config/nvim
Why do people always expect the average joe user to understand this? What do I do with this? Do I run this in the terminal? Then what? First line opens Vim and it opens 11 files. Now what? This seems like the average explanation that works for the person who writes it, but is useless unless you know this already.
for vim do: sh mv ~/.vimrc ~/.vimrc_bak mv ~/.vim ~/.vim_bak git clone https://github.com/SpaceVim/SpaceVim.git ~/.vim
for nvim do: sh git clone https://github.com/SpaceVim/SpaceVim.git ~/.config/nvim
This is awesome! For someone coming into the more "conventional" editor space scouring github/internet for plugins is a huge pain and its even harder to find ones that cover your cases and are kept up to date. Having this all rolled into one as and having it all work together in harmony is a big win for on boarding people to vim!
Disclaimer: I haven't tried this package but it does seem to have a lot of promise.
This uses NeoVim, for a similar bundle using Vim there's some options like Steve Francia's https://github.com/spf13/spf13-vim (called Ultimate Vim Distribution)
[+] [-] krzyk|9 years ago|reply
Is it a vim plus a bundle of plugins?
EDIT: Cleaned up the spacemacs sentence.
[+] [-] arnarbi|9 years ago|reply
Spacemacs is the same for Emacs.
[+] [-] wsdjeg|9 years ago|reply
[+] [-] Shicholas|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
If it was simple, there'd be an answer to this question: how do I setup Vim/Emacs as a fully feature complete IDE for C, C++, Rust, Go, Java, JavaScript (Node or Web), C#?
By feature complete I mean autocomplete, error detection, built in one-button-runs, automatic config/sane defaults.
Keep in mind this is a dream list. It's perfectly fine if the list only includes 2-4 of these languages but it needs to have all of these features.
Looking at this from the outside (people who use IDEs) in (onto the people who use Vim/Emacs) we have maybe 1 IDE/Language and that's confusing for us. I can't imaginge having 3 text editors all of which have different common dotfiles.
[+] [-] tom_mellior|9 years ago|reply
That's the promise of Spacemacs:
- clone their git repository into your .emacs.d directory
- run emacs once, answer three basic questions about your preferences
- add your list of languages to the "dotspacemacs-configuration-layers" list in your .spacemacs
- make it reload the configYou're done. All this should take less time than it took me to look up those "layer" names in the docs.
> By feature complete I mean autocomplete, error detection, built in one-button-runs, automatic config/sane defaults.
Yes, all that is the promise of Spacemacs.
If anything, I found it to be too much of a kitchen sink (it tries too hard to be "smart" about balancing parentheses for me etc.). Still, you might want to give it a whirl if you have 15 minutes. I ended up going back to vim for almost everything, and I'm on the line on whether to use Proof General from plain Emacs or from Spacemacs. But the time to check it out is not wasted.
[+] [-] sevensor|9 years ago|reply
> By feature complete I mean autocomplete, error detection, built in one-button-runs, automatic config/sane defaults.
By and large, I find features like these distracting to the point of unusability, which is why I like living in stripped-down editor land. Different strokes for different folks.
[+] [-] rayiner|9 years ago|reply
[+] [-] yakubin|9 years ago|reply
That said, I think many would agree that for C/C++ YouCompleteMe is a must-have. It has ctags functionality (but without false positives), error detection, autocomplete... And probably lots of other features I'm ignorant of.
There is a semi-official vim plugin for go. I used to use it when I was playing with this language. Same for Rust. I don't know about other languages you've mentioned.
As for the "distributions". I prefer to configure everything myself, but I get it that others might want everything preconfigured for them.
PS. Yes, I'd agree that vim has insane defaults. All vim config files I saw have a common part, I think.
[+] [-] Waterluvian|9 years ago|reply
[+] [-] caconym_|9 years ago|reply
When it does work, it's great. But the inconsistency is probably going to drive me away, back to Vim. I think that if anyone can build a similar thing for Vim that actually works, I'll use it in a heartbeat.
[+] [-] michaelmrose|9 years ago|reply
Regarding plugins you can use melpa and track the latest release of everything at all times.
You can use melpa and update most stuff infrequently save for the ones that are most important to you.
You can use melpa stable and run only stable versions of everything.
You can use melpa stable and run newer versions of a minority of plugins that are important to you.
What plugins you choose to use and and whether you choose stable or unstable could very well lead to vastly different experiences.
The best strategy is to carefully select plugins which are useful to you and high quality, and run the stable versions of most things updating your tools infrequently when a new major release adds something that looks useful to you.
[+] [-] quicknir|9 years ago|reply
The only other thing that can break you other than updating spacemacs is updating packages, but that's a factor with vanilla emacs and with vim. This happens occasionally but not too often.
Also keep in mind: spacemacs is not all or nothing. There are many, many layers that are higher in the dependency tree, that both get less attention and are easier to swap. For instance, even though I mostly develop in C++, I don't use the C/C++ layer from spacemacs. There were things I wanted that were missing (like rtags), and things that I didn't want that were there (like older tags solutions).
I started out by just configuring rtags inside a single simple file, the same way a vanilla emacs user would, and I dropped the C++ layer. I eventually added more stuff and wrote my own C++ layer. I'm quite happy with the result. I still got a ton of useful layers/packages from spacemacs that were easily setup and configured, like evil, magit, helm, company, flycheck, etc. And the whole layer system itself made even the parts that I customized myself more modular.
[+] [-] brudgers|9 years ago|reply
I don't think it's really possible to build something like Spacemacs for Vim because of the different underlying architectural decisions. Vim is a one-thing-only-and-do-it-well tool. Emacs is 'an operating system missing a decent text edtior'.
[+] [-] hxegon|9 years ago|reply
[+] [-] Philipp__|9 years ago|reply
[+] [-] the_duke|9 years ago|reply
Especially since I use quite a few different languages.
Ain't nobody got time for that...
[+] [-] towb|9 years ago|reply
[+] [-] scribu|9 years ago|reply
For example, this site listed some useful plugins that I didn't know about, such as https://github.com/bogado/file-line
[+] [-] PhasmaFelis|9 years ago|reply
This is one of the most obtuse project descriptions I've seen. If you're making a...whatever this is...aimed at Vim users, why would you expect them to be familiar with a something-or-other for Emacs?
[+] [-] verandaguy|9 years ago|reply
Taking that into account, this can be interpreted as "It makes Vim work more like Vim."
[+] [-] gregpardo|9 years ago|reply
[+] [-] chrismorgan|9 years ago|reply
[+] [-] ageofwant|9 years ago|reply
[+] [-] scrollaway|9 years ago|reply
The table rendering issues I suspect are from the lack of a newline after the headers. I don't know whether it's correct or not because, yknow, markdown.
Still better than rst. :)
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] ticoombs|9 years ago|reply
[+] [-] johncoltrane|9 years ago|reply
[+] [-] allover|9 years ago|reply
[+] [-] mavdi|9 years ago|reply
[+] [-] leblancfg|9 years ago|reply
What I haven't done is check neovim. Any comments regarding the potential for inline code execution?
[+] [-] chestervonwinch|9 years ago|reply
In my experience, you really can't beat Org-mode when it comes to inline code execution. You can preview LaTex and plotting inline as well. Plus, you can of course export the document into a variety of formats (HTML, PDF, etc.), which are quite customizable thereafter. Here is a document I put together with Org-mode for a short C++ seminar [1]. All the code is executable while editing the document in Org, which is nice for a number of reasons. I also added some custom CSS/JS for the HTML export.
[1]: https://htmlpreview.github.io/?https://github.com/notmatthan...
[+] [-] justinmk|9 years ago|reply
Try codi.vim for REPL-like eval:
https://github.com/metakirby5/codi.vim
[+] [-] hollander|9 years ago|reply
[+] [-] ageofwant|9 years ago|reply
[+] [-] yrro|9 years ago|reply
[+] [-] perlpimp|9 years ago|reply
[+] [-] Royalaid|9 years ago|reply
Disclaimer: I haven't tried this package but it does seem to have a lot of promise.
[+] [-] fao_|9 years ago|reply
[+] [-] justRafi|9 years ago|reply
[+] [-] drKarl|9 years ago|reply
[+] [-] desireco42|9 years ago|reply
For those who don't know what it is, it is showing possible keystrokes you can hit, which is super helpful when I was using new plugins and such.
[+] [-] unk|9 years ago|reply
[+] [-] justRafi|9 years ago|reply
[+] [-] hydandata|9 years ago|reply
[+] [-] slax0r|9 years ago|reply
[+] [-] Shicholas|9 years ago|reply