search

syl20bnr / spacemacs

A community-driven Emacs distribution - The best editor is neither Emacs nor Vim, it's Emacs *and* Vim!
http://spacemacs.org
GNU General Public License v3.0
23.67k stars 4.89k forks source link

Consideration for reduced number of default packages #52

Closed punassuming closed 9 years ago

punassuming commented 9 years ago

I was using Vim for 6 years before I tried Evil, and had finally gotten in the hang of using Emacs with multiple require 'init-packages until I found this repo. I really like the way you set up extensions and packages, in addition to having a call to an init function on each package load, which is very reminiscent to how I hacked Vundle to load some autoload functions based on the package name loaded.

One question I had was whether you ever considered refactoring some of the package definitions into separate contribution layers for some advanced features and languages. I know you can add a package name to a variable to not load it, but I have about 40 packages in that variable, (mostly language packages I do not use). The idea being that you basically have a bare bones emacs environment to still have a decent experience and then maybe make a spacemacs-advanced contribution layer that loads everything else (it can even be set as default).

syl20bnr commented 9 years ago

Indeed there are a lot of packages we can remove from the spacemacs layer. Thanks for opening this issue where we can discuss about this.

You are right about the spacemacs layer which could be as any other layer, it makes perfect sense but I think it could hurt one of the goal of the project which is to have consistency, especially regarding key bindings. One of the main point of spacemacs is to have the space key as the leader key and built upon it to have mnemonic and ergonomic bindings. Ideally contributions will stick with this scheme since it is at the core of it. So hopefully we will have a bunch of configuration snippets that fit well together regarding the key bindings and philosophy. If we achieve this, I think we will achieve something unique in the Emacs community.

Now your wish to have a base Emacs extended by configuration layers will come true in the future, maybe by us or by other people. The spacemacs project is also a playground for a contribution model I call Emacs Crown with the semantic field of the crown, jewel, cut etc... You can see some POC about this in my repositories. Emacs Crown name has been chosen because it is close to Crowd-Configuring which is the complementary of the package/plugin model. It can be seen also as a meta-package model but it is not accurate since it is focused on configuration, not on features per se.

Olical commented 9 years ago

Just my quick thoughts on the matter: I like the spacemacs packages, but that may well just be because they're sane defaults that match my approach. It's opinionated, but happens to match my opinion.

I guess the other approach I'd be happy with is an emulation of vanilla Vim with a plethora of layers for languages and environments that you can easily hook into. So adding javascript would integrate tern and flycheck with JSHint, for example. I personally don't care for the Erlang tooling, so that's something I wouldn't include.

With that in mind though, the packages I don't use don't get in my way. If they did I could easily disable them thanks to the ~/.spacemacs file.

punassuming commented 9 years ago

Thats' correct, I basically have been updating ~/.spacemacs with the packages I don't plan on loading. Having the ability to automatically delete the package if not referenced is a nice feature. I will continue thinking about the question and how learnings from Fugitive, Vundle, VAM, and NeoBundle can be applied to the Emacs working env.

syl20bnr commented 9 years ago

I like the layer per language approach a lot. Maybe we can organize the layers in categories:

These two categories are a good starting point.

For now if a package is listed in several layers, the last declared layer wins the right to initialize the package. With the approach suggested by @Wolfy87 we could change this behavior to get additive configurations and we could add a new function type beside layer/init-xxx which can be layer/config-xxx. The layer/config-xxx functions would be hooked to the :config property of use-package used in the layer/init-xxx function . It would work. Even the filtering would work.

Flycheck is a good case study for such a mechanism.

One more thing, the documentation model for spacemacs must take care of the additive configuration layers.

syl20bnr commented 9 years ago

This discussion can be closed, we already started and will continue to move packages to contrib layers.