~shom/EmacsVanillaChocolateSwirl

Vanilla Emacs with just a little swirl of smoothness for new users transitioning from "modern" editors/IDEs
Updated readme build for sourcehut repo.
Merge branch 'main' of codeberg.org:shom/EmacsVanillaChocolateSwirl
Added build automation for Sourcehut to generate readme.html

refs

main
browse  log 

clone

read-only
https://git.sr.ht/~shom/EmacsVanillaChocolateSwirl
read/write
git@git.sr.ht:~shom/EmacsVanillaChocolateSwirl

You can also use your local clone with git send-email.

Introduction

This was inspired by a discussion on the Emacs mailing list and as a new user (less than 6 months at the time of writing) creating a config was the best way for me to contribute to the conversation. Therefore, this is an attempt to create a literate config that can be presented as an option to a user migrating from "modern" editors/IDEs.

A lot of times these discussions are presented as a zero-sum game. The defaults don't need to be changed at all. However, a new user setup wizard (which launches only if a config isn't detected, so experienced users won't even have to hit cancel). The goal is to provide "sane" defaults and fresher UI to flatten the learning curve. Vanilla Emacs with just a little swirl of smoothness.

Goals

What it is

  • A way for me to understand Emacs config and package system better
  • Learn a bit of elisp syntax
  • Play with literate programming
  • Do the learning in public and hopefully learn from others

What it isn't

  • An Emacs "distribution" (I use doom-emacs it's fantastic and has an excellent community, I wouldn't have made it long with Emacs without doom)
  • Any claims about idiomatic ways of doing things technically or philosophically, I welcome constructive feedback.

Usage

If you want to try it out and suggest some improvements that would be fantastic (PRs welcome, info below)

git clone git@github.com:shombando/EmacsVanillaChocolateSwirl.git
cd EmacsVanillaChocolateSwirl
emacs -q -l ./init.el

Contributing

I absolutely welcome feedback in the form of PRs, whether it is finishing WIP sections or adding new ones. A requirement:

  • the contribution should be in the form of literate config explaining the why and not just the what.

A request:

  • please create one PR per package being configured so I can test and merge them independently.

If some configuration is super niche, we'll create an appropriate niche heading to group it under but don't let it stop you from suggesting ideas. Draft PRs are also encouraged if you want to collaborate more closely.

Thank you for helping me learn more.