1
0
Fork
You've already forked EmacsVanillaChocolateSwirl
0
No description
  • Emacs Lisp 100%
2022年05月05日 01:37:52 -05:00
.build.yml Updated readme build for sourcehut repo. 2022年05月05日 01:37:52 -05:00
.gitignore Reoganized and added readme 2020年09月18日 01:28:43 -05:00
config.org Vertico integration 2021年06月12日 04:21:17 -05:00
init.el bare minimum expected behavior 2020年09月15日 03:22:13 -05:00
LICENSE Added Apache license 2020年09月18日 06:35:53 +00:00
readme.org fixed merge mistake 2020年12月06日 08:31:48 +00:00

"Modern" Emacs experience for transitioning user

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.