Closed quanganhdo closed 9 years ago
Depends what you mean by minimal. We are migrating slowly packages from spacemacs layer into contrib layers so as time goes by we will have less packages installed by default. I don't have a goal number of packages for the spacemacs layer, it is essentially driven by usefulness of features, consistency and reasonably fast boot time, this could mean that we will surely still pack by default a rather big number of packages, at least biggest than just Emacs + Evil + Evil plugins.
You are free to tailor spacemacs as you like by excluding packages in your dotfile and distribute this dotfile to others. You can even make and distribute your own distribution of spacemacs, say minimal-spacemacs
, and so on... :-)
The way I see it, spacemacs is a combination of sensible key bindings under the SPC namespace, and a collection of useful plugins. The bindings alone reduce Emacs' complexity and the need to remember shortcuts a great deal. They serve as a gentle introduction for Emacs newcomers like me.
The packages themselves seem to gear towards programmers. While I understand their usefulness, I think it'd limit spacemacs' targeted audience.
Take me as an example: I'm not yet ready to move wholesale from Vim to Emacs as an IDE, but looking to try out org-mode. Without spacemacs, I would've had to first get acquainted with Emacs' vast amount of shortcuts and different ways of doing things. Now I only need to remember a few SPC bindings to get started, and I think that hits the sweet spot. The programming packages seem 'extras' to me and should be opted in.
Anyway, thanks for your great efforts in building this ;-) I'd use spacemacs for sometimes and maybe create a minimal
contrib like you suggested.
You're right and I think this is what we started to do, programming languages are being moved to contrib/lang
for instance. I guess that this combined with moving project management to its own contrib layer will unclutter a lot the spacemacs layer for non programmers. There as certainly more layer we can create that I don't think about right now.
Overall it seems that your vision matches what the spacemacs layer will be over time :-)
I was thinking about this: What about a whitelist function that if non-nil, only allows packages to load from the supplied list. The problem with the exclude function is that it requires you to continually update with new packages that get added to the repo.
We already have this, these are the layers. I understand that for now the spacemacs layer is big but it takes time to re-architecture it into more modular layers. Spacemacs has been getting attention for less than 2 months, it's very young.
Whitelist is a trade-off you gain on the sides you mentioned but you lost on other sides. Layers are tailored to be 0/1 easy choice. In this context it makes more sense to provide an exclusion system for packages and finer granularity than an inclusion one which will put the burden on the user to re-make from the ground up a layer.
I moved around 20 packages in different layers, will be available in v0.32.0. There is still work to do but some of the packages required addition support at the config-system level.
Wow, just saw the commits. You've been busy :) I get what you say about the inclusion / exclusion issues.
@quanganhdo What do you think about the last migration of packages to their own layer ?
Another question, what do you think about an org
layer ?
I think org and advanced lisp (eldoc, ielm, slime) should be added. I am starting to migrate some of the lisp out now. A few packages weren't loading properly.
@syl20bnr Great move (literally). I think an org
layer will benefit as well.
I close the discussion. Feel free to reopen it if you feel that the topic has not been enough covered.
Not sure if it's been discussed before, but is it okay to have a layer with the minimum amount of packages? I think it'd still be benefical to Vimmers loving to try their hands on Emacs + Evil.