I wish people stopped calling a shared config a 'distribution'
In both Spacemacs and Spacevim, all that's being provided is a config. No runtime, no package manager, no changes to the actual binaries of either app.
Using and customizing SpaceMacs is considerably different from using plain emacs.
They use their own config system, their own plugin system (aka layers), and the user experience is very different, right from the start.
Of course it's emacs underneath, and you can still do much as with plain emacs, but it's different enough for it to be more than "just a config for emacs".
It's just a config for emacs. Sure it has some functions and life-cycle hooks for you to change a few things here and there, but in the end it's a glorified config. You delete .emacs.d and you're back to default emacs.
In emacs, thanks to Elisp, you can't really distinguish between a config and a plugin, because most 'configs' use actual code to (often extensively) alter the editors behaviour.
It's a well thought out config for Emacs. A layer is just a list of use package statements with some config to make it work with the leader concept and vim bindings if that's set.
You can still install Melpa packages quite easily and you can still bind keys however you want. It's still Emacs.
Is there a clearer more understandable word? Your definition of 'distribution' sounds like something much more specific (changes to binaries?) than mine.
At risk of putting words in the another poster's mouth, I don't think the idea was that a distribution needs to have changes to binaries, just that it has to include the whole thing. I think the notion is that since you don't get your build of Emacs as part of Spacemacs, Spacemacs isn't a distribution of Emacs. I tend to agree. I think it could be a distribution of Emacs even if it were just upstream Emacs plus a simple conf file, but the key is that it has to include the thing it is a distribution of.
Thank you for filling in the blanks. You pretty much summed up my definition.
I can only guess at the reason why Spacemacs team chooses this term, but there is one simple problem with it.
Users of Spacemacs are encouraged (by this naming quirk) to treat it as somehow essentially different to Emacs. That's wrong.
It would be of benefit to all for the code that comprises Spacemacs (layers mainly) to be released as packages. It would place greater emphasis on Emacs as the actual core product, and allow people to use and collaborate on smaller chunks of Spacemacs, without the monolith problem.
Not familliar with SpaceVim (yet) so I can only speak for Spacemacs.
Emacs has really bad support for writing modular code (~/.emacs/init.el), and Spacemacs adresses this issue. Also a lot of work went into integrating various packages and modernizing emacs experience. To give an example, Spacemacs out of the box had 90% of features that my custom-crafted ~2kloc config file did. And I find the (new) shortcuts so intuitive that I am considering adding them to my vimrc.
> No runtime,
Spacemacs loads your config (very fast I might add), adds a nice startup screen, gathers statistics about your config etc.
> no package manager
It also bundles use-package - which is a package manager. And makes bootstrapping emacs on a new machine trivial.
> no changes to the actual binaries of either app
Remember this is emacs. You don't need to rewrite any part of it, you can change anything with advices/hooks, and it is actually easier to do than patching some random packages.
The difference in Emacs vs Vim is Emacs-Lisp. This means Spacemacs is incredibly more powerful than Spacevim from a conceptual point of view.
Emacs is a living, self-documenting environment and Spacemacs extends it quite a lot. This Lisp environment is very different from a set of plugins developed offline or mere configurations.
Calling Spacemacs a bunch of plugins and configuration is like calling any conventional program a plugin of its language and runtime. Plugins attach to an environment with a specific runtime API, instead of extending said API, blurring the line between runtime and extension in the process.
Spacemacs is the same for Emacs.