Closed jone closed 12 years ago
Re-added e-max-theme
as custom with default value. Startup does not fail anymore when it is not set.
I've split up default bundles and additional bundles, so that default bundles are not listed in the users .emacs.d. This makes it easy to update the default bundles in future, but the user can still disable default-bundles by setting e-max-disabled-bundles
. I've also updated the ~/.emacs.d/config.el template.
I've added a wiki page at https://github.com/senny/e-max/wiki/Bundles . I think we need to provide some docs about the bundles (what does it? what can I configure?). Since the wiki is also a repo and the pages are .md files we can easily move it to a e-max website later.. We should definitely clean up default / additional bundles, as we already discussed - but I think this would be the next step.
Maybe we could also add a readme.md per bundle in the source and sync it to the wiki or a website. I'd like to have both, in source docu as well as web-based docu.
What do you think @senny? Especially keep a look at the custom.el template, I've removed the long list of bundles and added just a few as examples - not sure about that yet. You may not be happy with that ;-) thoughts?
I like most of the changes. A few points I notices:
e-max-theme
variable back in and then use theme-roller-default-theme
in the custom.el template?accessibility
it only makes sense to customize certain behavior e-max uses per default, like line-numbers etc..regarding the split of "library-functionality" and "bundles" I would rather have a full list of bundles in the config.el file but convert most of the default bundles into library functionality. Bundles should be a pack of functionality that the user knows if he uses it or not e.g. ruby, python, org, git, svn, html, css, sass, ...
e-max-theme
: I forgot the theme-roller-default-theme
. I've now removed the custom.el completely, since emacs will create it if needed. If the user customizes things manually, he should anyway not put them in custom.el but e.g. in local.el or config.el, I think.local.el
: I've changed the load order and added a comment - but I'm not sure how to explain the use simple and understandable :) thoughts?bundles
: So, in a longterm view, should there be any "default-bundles" like we have it at the moment? I mean: at the moment we have bundles like html, ruby, etc. which are enabled by default.
html
at all and the user has to actively decide / configure it in config.el?html
in the config.el
on install, but it is not a "default bundle" but only a suggestion? Which bundles should we enable in this case by default?e-max-disabled-bundles
stuff and put back the full list?Btw: I didn't change the set of bundles, because it is too off-topic. But I think we could merge this pull-request into a "v2"-branch where we can clean up the bundles before giving it to the crowd ;)
@jone, yes I think you should close this pull-request and re-open one with the merge-target of v2. This will give us greater flexibility in changing the internals because 2.0 will not be backwards compatible anyway.
regarding the discussion of "bundles" and "default-bundles". From my point of view. A bundle is something the user chooses if he wants to use it. I would consider every programming language a separate bundle. The user then chooses in config.el
which bundles he uses. If a new one is added to e-max, he must manually add it to the list.
on the other hand we have "opinions" about how emacs should be configured. The opinions can be dependent on variables like e-max-show-line-numbers
but we give the user the experience we thing is a good starting point. These features should be added by e-max and should not be located in a bundle.
to answer your question: Yes I think there should be a list in config.el
where ruby, python and html are present. But the user should know what the terms mean and he should be able to decide if he wants it or not, without studying tons of documentation. So bundles like accessibility
don't really reveal their intent its just a big ball of customization, which e-max should perform anyway.
I've worked on the install.sh and the .emacs.d templates, as discussed in #59.
.emacs.d template:
~/.emacs.d/init.el
to~/.emacs.d/bundles.el
~/.emacs.d/init.el
now only defines the e-max-path and loads e-max. It is not meant to contain any other things.~/.emacs.d/local.el
is created.~/.emacs.d/custom.el
is created.~/.emacs.d/bin/update-e-max
is created, symlinked to update.sh.install improvements:
e-max-theme
I've removed the
e-max-theme
variable (was in init.el). This was redundant, since the theme roller defines atheme-roller-default-theme
custom - I've defined the default in custom.el. For me it was confusing - e-max-theme didn't really do anything.. @senny what do you think about this one?Updating
We need to be able to update .emacs.d with the update script somehow. But I'm not sure about what exactly should be done and what we will need in the future.
I'm also not sure about if and how we update the current user - should ensure somehow that they do have e.g. a bundles.el?
@senny please review. Webinstall is not easily possible to test on a non-master branch, so I'd just run it from a local clone..