Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to add :use keyword to layer declaration #5190

Closed
sooheon opened this issue Feb 22, 2016 · 10 comments
Closed

Proposal to add :use keyword to layer declaration #5190

sooheon opened this issue Feb 22, 2016 · 10 comments
Assignees
Labels
- Mailling list - Proposal stale marked as a stale issue/pr (usually by a bot)

Comments

@sooheon
Copy link

sooheon commented Feb 22, 2016

In the spirit of being explicit about what you would like to use, rather than excluding what you don't want, a :use keyword for the dotspacemacs-configuration-layers list would be useful.

Specifically for adding on to spacemacs-base, currently the layers like spacemacs-ui spacemacs-evil etc. still come whole hog, and you end up adding most of spacemacs default back if you want something in the layers. This would allow you to be more selective, more easily.

'(better-defaults
  (spacemacs-ui :use '(info+ window-numbering))
  clojure)
@a13ph
Copy link

a13ph commented Feb 23, 2016

I suggest keyword "only" instead of "use".
In my opinion it is much more self-evident that "only" those packages are used, rather than additionally or selected from some optional ones (like choosing backend, for example).
However, if it's used somewhere else (use-package?) extensively and therefore will be more consistent, I'll retract

@sooheon
Copy link
Author

sooheon commented Feb 24, 2016

I agree :only is more clear about the meaning.

@sooheon
Copy link
Author

sooheon commented Feb 27, 2016

:exclude as a layer argument may also make sense, because this keeps layers atomic, rather than putting the exclusions in a dotspacemacs variable, which can fall out of sync with the actual layers I'm using.

@a13ph
Copy link

a13ph commented Mar 1, 2016

@sooheon I very much agree on the :exclude proposition too. Global exclusion has it's merits, but it's not in line with layer way.

@justbur
Copy link
Contributor

justbur commented Mar 1, 2016

If I could add to this, I like the idea of having the ability to include or exclude packages but not the separate keywords because then you need to specify rules about what happens when both are used. If the choice were mine, I think I'd do something like this

  (spacemacs-ui :packages (info+ window-numbering))
  (spacemacs-ui-visual :packages (not neotree))

@syl20bnr
Copy link
Owner

syl20bnr commented Mar 1, 2016

👍 to @justbur's proposal.

@sooheon
Copy link
Author

sooheon commented Mar 1, 2016

If I want spacemacs-ui, but just without window-numbering, I think the explicit :exclude will be useful.

(spacemacs-ui :packages '(ace-link
                          ace-window
                          buffer-move
                          (centered-cursor :location local)
                          desktop
                          (doc-view :location built-in)
                          flx-ido
                          info+
                          open-junk-file)

(spacemacs-ui :exclude '(window-numbering))

The rules for both being used should not be complicated, and it should be no different than if someone has defined :packages for a layer, and excluded some other package used by that layer globally, so we need to hash out the precedence anyway. I'm leaning toward :exclude taking precedence, if we see current layer declarations as implicit :use for all its packages.

The benefit is that we gain atomicity for layer declarations, as said before. I don't need to include a whole layer, then exclude bits of it globally, which is brittle.

@justbur
Copy link
Contributor

justbur commented Mar 1, 2016

@sooheon you missed that I had a not at the head of the list in the second example. The idea was that :packages (not ...) would exclude packages.

@sooheon
Copy link
Author

sooheon commented Mar 2, 2016

@justbur I did! That was much more elegant than what I had thought. Scratch my proposal above, yours is much improved.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Feb 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
- Mailling list - Proposal stale marked as a stale issue/pr (usually by a bot)
Projects
None yet
Development

No branches or pull requests

5 participants