Discussion: How to make spacemacs layer a meta-layer

[justbur]

This is a continuation of the discussion in #2546.

We now have a minimal "distribution" of spacemacs, called spacemacs-base. The next logical step is to allow users of spacemacs-base to pick and choose functionality from the full spacemacs layer, creating your very own super customized version of spacemacs. One way to accomplish this is to make the full spacemacs layer a "meta-layer" that loads other layers. The purpose of this issue is to discuss how splitting up the packages that are in spacemacs, but not spacemacs-base might/should occur. This is just hypothetical for now.

Here are all of the packages that are currently in spacemacs but not spacemacs-base, and this is a very rough attempt at breaking the functionality up into new layers.

Editing (More Functional)

• aggressive-indent
• pcre2el
• clean-aindent-mode
• move-text
• smartparens
• hungry-delete
• avy
• iedit
• eval-sexp-fu
• expand-region

Editing (More Visual)

• auto-highlight-symbol
• rainbow-delimiters
• adaptive-wrap
• highlight-indentation
• highlight-numbers
• highlight-parentheses
• hl-anything (currently disabled in spacemacs)
• linum-relative
• indent-guide
• volatile-highlights

Emacs UI (More Functional)

• ace-link
• recentf
• ace-window
• centered-cursor
• info+
• open-junk-file
• desktop
• flx-ido
• buffer-move
• window-numbering

Emacs UI (More Visual)

• fancy-battery
• powerline
• ido-vertical-mode
• zoom-frm
• smooth-scrolling
• vi-tilde-fringe
• neotree
• golden-ratio

Evil Enhancements

• evil-anzu
• evil-args
• evil-exchange
• evil-iedit-state
• evil-indent-textobject
• evil-jumper
• evil-lisp-state
• evil-nerd-commenter
• evil-matchit
• evil-numbers
• evil-search-highlight-persist
• evil-terminal-cursor-changer
• evil-tutor

Helm Enhancements

• helm-ag
• helm-make
• helm-mode-manager
• helm-swoop

Language

• auto-dictionary
• define-word
• google-translate
• spray

Themes

• helm-themes
• leuven-theme
• solarized-theme

Utilities (?)

• doc-view

[stshine]

I think avy, helm-swoop and powerline are must-have. There previous two are important jumping and searching functionalities and have important key bindings. And I know people who use spacemacs for its beatiful mode-line.

[justbur]

Sorry for the confusion. This discussion is not about what is "must have"
or not. You will always be able to get everything from the full spacemacs
layer.

The question I'm asking is in the future how do we logically group these
packages for people who want to start from a minimal version of spacemacs
(called spacemacs-core) and build up to their liking.

On Tue, Sep 8, 2015 at 12:22 PM, stshine notifications@github.com wrote:

I think avy, helm-swoop and powerline are must-have. There previous two
are important jumping and searching functionalities and have important key
bindings. And I know people who use spacemacs for its beatiful mode-line.

—
Reply to this email directly or view it on GitHub
#2937 (comment)
.

[cmccloud]

At the moment is it possible for a user to specify packages from the spacemacs layer to exclude?
e.g. something like
(spacemacs :excluded (auto-dictionary define-word google-translate))

[person808]

@cmccloud The dotspacemacs-excluded-packages variable works

[cmccloud]

Fantastic. Thanks!

[sooheon]

Excluding unwanted packages is the way I do it as well, but @justbur's idea has a lot of merit. Adding in the piece you want is a lot easier to keep track of in your head than excluding everything else. +1 to the first pass of categorisation as well.

@justbur What do you mean exactly by "meta-layer" though? We already have the abstraction of layer, and layers grouped within folders, we should just make these another set of layers, no?

[justbur]

@sooheon The idea is that these categories would become layers and then the spacemacs distribution would just load these layers by default. Maybe meta-layer is the wrong word

[robbyoconnor]

👀 -- Just watching this

[louy2]

I feel I am not even using half of the listed functions...

[a13ph]

TLDR: Base should be only universal sensible defaults, but it should be very easy to find and install layer or package needed (for a feature/use case/profession/language/editor migration/...)

While I'm unsure if that's a good place, I'll try to pitch in some ideas here: there's an opinion (not mine, but not without merit) that it's a bad idea to use starter kits which add a lot at once, since you end up trying to dig into superfluously installed bits to understand them, instead of adding step by step, managing complexity and understanding.

But if we strip away and package/layer things as optional, discovering them would become harder than simply reading which-key or various helm symbols(functions, vars...) listings.

Therefore this change may additionally require some better discoverability support not only for already installed, but for available layers and packages too.

This already pops up as questions from newbies about available layers, which usually gets answered by pointing to a layer directory - despite directory tree not being neither most supported nor most used feature discovering source. (From my experience with using/helping others use Emacs and software in general)

[louy2]

What about asking more questions at first startup? We already ask whether vim or emacs. Adding languages of choices after that seems legit, and the default .spacemacs can be generated accordingly.

[a13ph]

Despite thinking about "asking more questions at installation" myself while
trying to solve accessibility of emacs for various specialists, I doubt
questions are as good at scaling and discoverability as other UI solutions.
For many cases there is already a UI pattern/element which can be used.

Currently utilized questions at spacemacs installation are hard to read -
horizontal ido style is really weird with it being a list in sequential
form which changes positions around...

This boils down to search, mostly and/or menu selection. Unless we want
something crazier, like autocompletion of layers or even their feature
synonyms, while in .spacemacs

On Tue, Nov 24, 2015 at 12:36 PM, Yufan Lou notifications@github.com
wrote:

What about asking more questions at first startup? We already ask whether
vim or emacs. Adding languages of choices after that seems legit, and the
default .spacemacs can be generated accordingly.

—
Reply to this email directly or view it on GitHub
#2937 (comment)
.

[louy2]

Then, we probably need something on the home screen. Recent files are not so important IMO when they can be accessed from helm. The home screen better consists of some starting guide, a list of available layers, and ... Oh wait. There's already a "quickhelp" as the little question mark button. I think it should be default instead of important notes. Put important notes there only after an update to inform the user of breaking changes is more sensible.

[person808]

There's already a "quickhelp" as the little question mark button. I think it should be default instead of important notes. Put important notes there only after an update to inform the user of breaking changes is more sensible.

Agreed. #4084 addresses this