Update install script.

[jone]

I've worked on the install.sh and the .emacs.d templates, as discussed in #59.

.emacs.d template:

• Moved bundle-list from ~/.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.
• A user-specific config file as well as a machine specific is created.
• A ~/.emacs.d/local.el is created.
• A ~/.emacs.d/custom.el is created.
• A ~/.emacs.d/bin/update-e-max is created, symlinked to update.sh.

  install improvements:

• More verbose output. The user should see what is happening.
• Before doing anything, the changed paths are listed and the user can confirm.
• At the end there is a short summary with paths to configuration files and urls.

  e-max-theme

I've removed the e-max-theme variable (was in init.el). This was redundant, since the theme roller defines a theme-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..

[jone]

Re-added e-max-theme as custom with default value. Startup does not fail anymore when it is not set.

[jone]

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?

[senny]

I like most of the changes. A few points I notices:

• Why did you introduce the e-max-theme variable back in and then use theme-roller-default-theme in the custom.el template?
• There is a lot of functionality in the default bundles I don't consider bundles anymore. I'm fine with taking this approach for the moment but I see the default bundles more as e-max lib components than bundles. It does never make sense to for-example disable accessibility it only makes sense to customize certain behavior e-max uses per default, like line-numbers etc..
• the local.el template should contain a commet stating what it's use is.
• the local.el file should be loaded last because it's the last resort to overwrite something from the other configuration options. Currently the user-config and the machine-config are loaded afterwards...

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, ...

[jone]

• 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.
  • Should we not enable html at all and the user has to actively decide / configure it in config.el?
  • Are we going to put 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?
  • Maybe distinguishing default and additional bundles is not the right approach. Should I remove the 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 ;)

[senny]

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