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.69k stars 4.89k forks source link

Minimal layer for non-programmers #260

Closed quanganhdo closed 9 years ago

quanganhdo commented 9 years ago

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.

syl20bnr commented 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... :-)

quanganhdo commented 9 years ago

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.

syl20bnr commented 9 years ago

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 :-)

punassuming commented 9 years ago

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.

syl20bnr commented 9 years ago

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.

syl20bnr commented 9 years ago

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.

punassuming commented 9 years ago

Wow, just saw the commits. You've been busy :) I get what you say about the inclusion / exclusion issues.

syl20bnr commented 9 years ago

@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 ?

punassuming commented 9 years ago

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.

quanganhdo commented 9 years ago

@syl20bnr Great move (literally). I think an org layer will benefit as well.

syl20bnr commented 9 years ago

I close the discussion. Feel free to reopen it if you feel that the topic has not been enough covered.