Proposal: Split spacemacs layer into spacemacs-core and spacemacs-extra #2546
Comments
|
I went through the list and except for a few obvious packages that should be moved to proper contrib layers I did not see a lot of eligible packages for an optional Spacemacs-extra layer. But we can do the exercise of defining what is the "Spacemacs experience" and maybe we can start to see some patterns. For me the "Spacemacs experience" is (in no specific order) use-package, evil, helm, projectile, powerline, UI improvements (expand-region, iedit, golden-ratio, volatile-highlights, fancy battery...). It seems that from this list we should be able to remove a lot of packages, it ends up harder than expected. |
|
Maybe the "spacemacs experience" is not the right phrase or describes -core and -extra together. I think it would be a useful exercise, even if you decide not to change anything afterwards. I will try to come up with better definitions than these, but I was thinking of roughly features that are used throughout vs. features that are easily avoided. I am not thinking of some being more important. It's something like describing a dependency tree. For example, from the ones you mentioned I see them splitting up into -core: use-package, evil, helm, projectile, powerline, volatile-highlights (maybe -extra) The -extra are ones that I can easily avoid using in any spacemacs session. Again, it's not a value judgement, because I use iedit and expand-region a lot. It's more of a question of does every spacemacs user need this for spacemacs to work for them? Does that make sense? In tandem with this, I would suggest subdividing -extra into layers. What's really nice about layers is that they are independent of one another, and I can feel comfortable adding or removing layers. Trying to manipulate the current spacemacs layer through excluding packages is tricky and to some extent requires understanding how the spacemacs layer treats that package throughout. |
|
This is the kind of thread where everyone will have a different view on what is extra and what is not, I'm maybe the most biased on this question ;-) To be more concrete, here is a first list of packages movable right now:
That is not so much. Now my understanding of building an extra layer is that it is very hard to achieve since everyone will have a different set in mind, I guess the best is to let people to build their own list by filling |
|
Yes, absolutely and I'm not interested in what people's favorite packages are. That's not an argument I want to start. To use an analogy, I'm thinking of the "arch linux method" of customizing spacemacs and the "ubuntu method". Under the arch linux method you start from a minimal core set of packages and add layers to your liking. Under the ubuntu method you start with a bigger set of core+recommended packages and make changes from that point. I personally think there's value to supporting both methods. Ubuntu is for someone who wants something that works off the shelf and doesn't require tweaking beyond maybe adding a layer or two. Arch linux is for someone who wants the "base" packages nicely configured for them (helm, evil, etc) and is willing to invest the time learning about and adding extra layers as they see fit. I don't know if this matches up with how you think about things. I think spacemacs strikes a good balance as it is now, and you don't need to change it. I opened this issue mostly to see if others saw value in creating a pruned down -core spacemacs layer. |
|
Very interesting, thank you. As you said it is a good exercise to do. Just for fun I'll try to do it with the goal to have the strict minimum of packages to be able to edit text and programs. Maybe I'll get surprised about it :-) |
|
A core, minimal version would allow for work to be concentrated in the core experience and overall stability (which, as I see it, becomes more and more important as the project matures to leave the beta). Also, I believe the experience of slowly customizing with the packages you understand you want is a richer one, where people slowly progress to understand how to add layers and configure Spacemacs. I'm very new to Spacemacs and the feeling I still have is that it is a rabbit hole way too deep for beginners. Having the extra would allow me to have a better grasp of the basics while at the same time allowing people with more understanding or less patience to jump head first in a full experience. |
|
I have one more thought related to this to throw out there. I would like it if the layers in contrib were more "atomic". A simple example is syntax-checking which includes both flyspell and flycheck. It's both convenient that both can be installed together and annoying if you only want one (because then you have to fiddle with excluding packages). What if we implemented layer groups in a very simple way: There's a folder called !syntax-checking that includes the now independent flyspell and flycheck layers, and I am able to put !syntax-checking in my .spacemacs to get both or just flycheck to install just one. More generally what I'm suggesting is to break up layers into atomic units, where you'd have to decide what atomic means, and allow people to add folders consisting of multiple layers to their .spacemacs if they want to install every layer in the sub-tree. Having atomic layers is good because it clearly separates the functionality into independent units (this should also make testing easier). To compensate for there now being many more layers, use the layer grouping to make declaring what you want in .spacemacs easy. To connect this to the above discussion, imagine that !spacemacs-extra is just a folder with a listing of the layers that recommended, and one can put !spacemacs-extra into .spacemacs to get all of them or pick and choose individual layers from within the folder. A side benefit is that .spacemacs becomes more explicit about exactly what you want to have. I no longer have to install a big layer and then blacklist components of that layer. Finally, this would give another way of browsing layers. You just browse the directory tree. You could do this from your phone even (maybe you already do this, because you figured out how to compile emacs for your phone). I would also add an INDEX.org file that included a table of contents linking to each of the layers (another version of |
|
I planned to move flyspell to a I see another level of abstraction between packages and layers as over-engineering and unnecessary complication. With layer we have already a semantic unit to group packages, then packages can be excluded to refine this semantic and fit anyones need. Layers have to be smartly defined and they can be easily rearranged to improve their semantic in a practical context. |
|
Fair enough. I hope this didn't come across as criticism. I was more just interested in what you and others thought about the idea. |
|
BTW, what you want is a tagging system. Which I plan to implement at some point to replace categories (but originally it is more for exploration than addition of layers). |
|
Yes, tagging would be the more general implementation. I suppose the value depends on how many layers there are. To me one of the really valuable (if not most valuable) contributions of a project like this is the work that goes into defining what those semantic units are and constructing them in a way that they can be independent building blocks for your system. There's a lot of great packages out there, but it's a headache having to think about how to set them up and especially how they interact with one another. |
Criticisms are positively expected as long as their are constructive and all your proposals largely fit into this category :-) |
Indeed 👍 On this subject, I prefere the approach of layers with larger scopes (with very abstract semantic) and then cut them into more concrete layers, syntax-checking and auto-completion are good examples. To remove neotree from the spacemacs layer I don't want a |
I have no problem with that approach and understand it, even if I prefer a slightly different one. I thought there might be a way to support an alternative without adding much in the way of complications (which I don't like either by the way). |
|
I don't think this issue needs to stay open |
|
@justbur I keep this in mind and will try to do it at some point. |
|
Ok, I don't think it's a big deal given all of the other stuff to be done |
|
@syl20bnr Love it! Now we need a way to selectively add parts of the spacemacs layer so that someone can build a super custom version of spacemacs. I was thinking about adding layers for the packages that are in the difference between spacemacs and spacemacs-core. We can explain in the readme that these layers are included in the spacemacs distribution and only make sense to add if you are using spacemacs-core, as well as printing a warning message to this effect based on the value of the distribution variable. What do you think? |
|
@justbur The new Edit: In fact, I see that's what is done at the moment with |
|
@TheBB Could you explain a little more? I haven't had time to go through all the new stuff yet. |
|
There's a new function called
|
|
@TheBB Nice! Yes, that's exactly what I wanted to do. I didn't want to really introduce full-blown layer dependency graphs, but using it in this case makes perfect sense. And that's the essence of what the original proposal was, to mimic package groups in linux. |
|
I tried to come up with some groupings that might work as layers that make up the spacemacs layer. They are far from perfect Editing (More Functional)
Editing (More Visual)
Emacs UI (More Functional)
Emacs UI (More Visual)
Evil Enhancements
Helm Enhancements
Language
Themes
?
|
|
Very interesting, I don't want to push the concept further for now but the mechanism is in place to start thinking about it. For now it is just transparent for users and I don't think it is necessary to document it in 0.104.0. @justbur can you open a new discussion with your last comment, it is a great starting point for the topic. |
|
@syl20bnr I completely agree, and I was surprised you did this now. There's no need to blow up the spacemacs layer right before a release :-) |
|
I guess I was in the mood for it (the moment I chose to be inspired may be not the best though) :-) |
|
@syl20bnr No complaints from me. spacemacs-core loads a second faster for me and seems to work perfectly. |
I don't mean to over complicate things, but #2523 and #2435 made me think of this. I was wondering if it could make sense to split the spacemacs layer in two, spacemacs-core and spacemacs-extra? The first would be the packages that are absolutely necessary to "the spacemacs experience", while the second would be nice-to-have or recommended but not critical. Anything in -extra could also be available individually the same way package groups work in linux package managers (https://www.archlinux.org/groups/), except this would be a "layer group".
The default could be to use both layers, but the separation would easily allow someone to strip out anything that's not critical in one step. It would also mean that including a package in spacemacs-extra does not mean automatically installing it for everyone. I imagine that I would start with both, and then gradually cherry pick the layers from -extra that I liked and remove -extra, creating a custom installation.
The text was updated successfully, but these errors were encountered: