About to declare Emacs bankruptcy. Any advice for cool or new packages, defaults, or ideas I should use before I start building my init.el? Also interested in guides to using evil.

I use Emacs mostly for research in the humanities. Linking to PDFs, storing notes, annotating documents, and writing and editing documents. I think my key packages are pdf-tools, org mode, org-roam, org-transclusion, org-remark, and org-roam-bibtex with citar. I use straight.el + use-package to manage my packages. I do a lot of my reading Zotero and then export stuff to Emacs, but I'd be interested in moving more to Emacs too. Currently using selectrum, but I hear that's being phased out in favour of vertico. I've liked prescient and I believe there's a hack to use it with vertico. I have consult installed too, although I haven't used marginalia or corfu yet. Interested in using them though! Any other cool packages that might work for my use case of finding documents, writing documents, and displaying connections between them? Or just quality of life improvement stuff? E.g. Zotero or Firefox integration, better buffer management, better scrolling, UI stuff. I've heard a lot of great things about evil, so interested in adding that to my init, but I've never used vim by itself. Any cool guides to getting started with evil that don't assume vim knowledge? And what additional elements of the evil ecosystem should I add? I can't tell the difference between [org-evil](https://github.com/GuiltyDolphin/org-evil) and [evil-org](https://github.com/Somelauw/evil-org-mode).

For evil, there is `evil-collection` that provides integration into most builtin modes and common external packages. Check out their site at [https://github.com/emacs-evil/evil-collection](https://github.com/emacs-evil/evil-collection]).

Thanks! This is one where options are a bit overwhelming to me lol. I see that evil-collection says it provides minimal org support. It apparently integrates with [org-evil](https://github.com/GuiltyDolphin/org-evil) and [evil-org](https://github.com/Somelauw/evil-org-mode), but it's not clear to me if there's substantial differences between them. And since I spend a lot of time in org, that might make some difference to me.

Quality of life: - The file manager [Dirvish](https://github.com/alexluigit/dirvish). You know how the veterans say that Dired is the best file manager? Well, with dirvish even mere mortals can agree. It has panes, a pretty UI, and even pdf preview through pdf-tools. - install [which-key](https://github.com/justbur/emacs-which-key). It's literally the perfect extension. There is no reason not to use which-key and you will be glad you have it some day. - you mentioned marginalia. Also a perfect extension: very little configuration, just sits there and makes everything better. Evil: Honestly, most vim usage tutorials are compatible with evil. ThePrimagen on YouTube has a good series, though he does have some negative thoughts on emacs (mostly legitimate criticism of how starter kits try to make it something it's not).

Maybe start learning elisp, if not already? Surfing on the edge of the newest and coolest packages might be fancy, but - as you attest with this post - does not make one stick to Emacs. Evil is a complex machinery build by vim nostalgic refugees, so familiarity with Vim's modal editing model is still recommended. I like this, even if it's not a tutorial: [https://github.com/noctuid/evil-guide](https://github.com/noctuid/evil-guide)

Usually when people are declaring "init bankruptcy" it's the result of trying too many things too fast without understanding them. Why not take your time and try each of these things incrementally?

So, there's certainly a lot of Emacs I don't understand and I might be moving to fast. I'm declaring bankruptcy because I feel like my init is pretty disorderd. E.g. random setting disconnected from others, unused packages, settings not ideally defined. I want to streamline what I've got with my main packages (listed above), switch to packages that are supported (e.g. selectrum to vertico), and try out new things to see if they improve my workflow. I also like knowing what's out there so I can have goals to work towards. Or if there's a really obvious addition I can make that would improve my workflow.

I'm trying to learn a bit of scheme, so I guess elisp wouldn't be a bad supplement. Is the best resource still the built in guide? Also, eh, I've been using Emacs for a year or so. I'm definitely sticking with it. Just trying to focus my use and make it a bit more liveable/explore the options of the space.

Oooh. Thanks. Definitely will add which-key + marginalia. And yeah, I found Dired pretty unintuitive, so I might give Dirvish a try. And thanks! I'll check out ThePrimagen. I've no issue with hearing Emacs criticism.

You might like to take a look at [crafted-emacs](https://github.com/SystemCrafters/crafted-emacs). The System Crafters youtube series on writing your own Emacs config, called [Emacs From Scratch](https://www.youtube.com/playlist?list=PLEoMzSkcN8oPH1au7H6B7bBJ4ZO7BXjSZ), taught me how to write an Emacs config. It was a really nice learning experience and taught me just how much is possible with a very minimal config. For `evil` specifically, I recommend that you use it alongside `general` (EFS video #3 for reference). If you want a relatively simple setup to compare, [here's](https://github.com/skyler544/rune-emacs-config/blob/main/modules/keybinds.el) mine. It follows the leader-key style from Doom, with the drawback/advantage that almost all of the user-defined keybindings are in this one file (drawback because it's not as flexible or complete, advantage because it's much simpler to grok). I can also vouch for corfu and friends (Marginalia, Orderless, Vertico, Embark, Consult); the philosophy behind the way they're written is appealing and setting them up / extending them is pretty trivial. Embark and Consult are particularly great. \[[Relevant corfu config](https://github.com/skyler544/rune-emacs-config/blob/222708871ec80178244ce69467956dee30d5b7ac/modules/utilities.el#L29-L69)\] \[[Relevant MOVEC config](https://github.com/skyler544/rune-emacs-config/blob/main/modules/movec.el)\] ​ EDIT: by the way, Consult+Embark are, to me at least, already all you need for better buffer management. `consult-buffer` has become my primary function for switching between different things I want to open, and if you use `embark-act` on a minibuffer item you'll see that all sorts of possibilities open up to you. This approach makes the minibuffer even more flexible.

you can try to reorganize things by making modules out of parts of your config. There is a drawback to this: slower init time. Check [this](https://github.com/skyler544/rune-emacs-config/blob/222708871ec80178244ce69467956dee30d5b7ac/modules/module-loader.el) out to see how easily you can do it with the help of `use-package`

Art is the elimination of the unnecessary. P. Picasso If I were you, I would skip straight.el, I see nothing that isn't in ordinary elpa/melpa/nelpa, so why using extra and not so small at all package, and add extra layer of complexity if you don't need it really? > Or just quality of life improvement stuff? which-key, helpful, beacon, auto-package-update, if you don't already use those. > Any other cool packages There are many cool packages for Emacs. My best tip is to explore packages one by one, and not install, 1001 new package at once. Maybe you should try Doom or Spacemacs if you are interested in Evil, and just use them without worrying which packages are installed/not installed? Just use the software, and once you encounter something you can't do in Emacs, do a search and see if there is something that helps you solve the problem. Otherwise, there might be a risk of "another init bankruptcy" or even "Emacs bankruptcy".

I'm not sure if there is a single best elisp resource :) (or that I'm that good in elisp to give advice). But I did like the \*style\* of an old book called "Writing GNU Emacs extensions" - which is probably obsolete by now. One advice that I've heard was to 'simply' study the source code of small emacs packages that interest you. I think it's also normal from time to time to 'purge' your init file and remake it, so to speak, taking each previously installed package, one by one, and asking yourself: do I really need this package? And if so, do I really need this and this tweak that I added last time? Or maybe there's a simple/newer alternative? And so on :)

Oooh. This is so cool. And it gives me an incentive to have emacs run and startup and use emacs-client.

> But I did like the *style* of an old book called "Writing GNU Emacs extensions" - which is probably obsolete by now. If there's one thing that's frustrating about Emacs, it's that since it has been around since the 80s, it's hard to figure out what older resources are still useful vs. not. Although, sometimes I like older programming stuff. I loved *Common Lisp: A Gentle Introduction to Symbolic Computing*. > I think it's also normal from time to time to 'purge' your init file and remake it, so to speak, taking each previously installed package, one by one, and asking yourself: do I really need this package? And if so, do I really need this and this tweak that I added last time? Or maybe there's a simple/newer alternative? And so on :) Exactly! I think my title was pretty bad. I thought Emacs bankruptcy meant something like 'my init getting out of hand, radically changing things up' not 'leaving Emacs'. Looking at the wiki, I think .emacs bankruptcy is what I meant to say. I'm not disappointed in Emacs. I'm excited because I got it okay, but want to go through a bit of pruning and planting phase with my init. And seriously, thank you for your advice!

Oooh. I've stolen some of his org roam config! I'll definitely check it out. And thanks for mentioning general.el and sharing your config. I heard about general a few days ago and that sort of inspired me to rethink my init. Also two potentially dumb questions: 1. Is there a name for corfu, marginalia, vertico, etc. I know they all act on Emacs completing-read system and they all complement each other, but I've been wondering if there's a name for the ecosystem as a whole? 2. So, the impression I have is that Embark let's you select and object and apply actions to that object, correct?

For straight, I think there were a few packages published on github but not in elpa / melpa that I wanted to try. Plus I think one package (elpher, maybe) was having difficulty installing using package.el but just worked when I tried straight. For the other advice, thank you! Spacemacs has been looking really tempting to me, but I've wanted to stick with vanilla Emacs and try to build something more personalised up.

I uninstalled `which-key`. I feel that the value it "adds" - also stops me memorising keybindings into muscle memory, I wait for the popup, then find a command - just to be sure that it is there, then type it. What do I use instead? `C-h`. For example, after a prefix to find keybindings for the prefix, like `M-s C-h` or `C-x C-h`. If I need to check a keybinding for a particular key at a given mode - `C-h k`. What keybindings that mode set? `C-h m`.

What is the purpose of using `use-package` in here? Wouldn't it work the very same way in the top-level of the module?

Re Evil: I learned those bindings by being a \*vi? user for a good few years (still am, toggling between Emacs and Neovim for different tasks every day). Maybe an idea to use \*vi? for a bit to internalize the bindings. It shines for tasks where many bells and whistles aren't really needed e.g.: opening elisp or Org files when your Emacs config is broken 🙊 -- I often find myself firing up Neovim in this situation. I think we all need a second editor to crawl back to when the music stops and Neovim could be that editor for you too while helping you get/stay comfy with those vi-like bindings. 😅 Thanks for mentioning org-evil and evil-org as I wasn't aware of these. For jumping between headings and other Org ops, I have resorted to learning the classic Emacs bindings. My prime use for evil was to avoid Emacs pinky issues so I've focused on reducing those, for me, awkward hand motions. I spend most of the time flying through buffers for which the basic evil bindings (`h`, `j`, `k`, `l`, `C-b` back a page, `C-f` forward a page, `H` top of page, `M` middle of page, `L` bottom of page, `/` for searching which is perhaps my primary way of navigating to bits of text 🙊) are more than sufficient. Strongly relying on evil bindings may put you in situations where there is more cognitive strain in navigating Emacs when the evil bindings conflict with the classic Emacs bindings or simply don't work well enough (certain modes, like the debugger or some Org modes kind of require the use of classic Emacs bindings for a decent experience). I still find myself entering `C-z` (`evil-emacs-state`) to switch to a "mode" (mode in the \*vi? way) where it is a bit easier to reason about the way Emacs will honor my input. Knowing "some classic Emacs bindings" is also helpful since some of the docs don't always list the updated evil bindings which can cause some minor confusion while trying to get things done. Lastly, classic Emacs bindings like `C-c C-b` (`org-backward-heading-same-level` and its opposite `C-c C-f`), `C-c C-c` (the Swiss army knife 🤣), `C-c C-t` (`org-todo`) and `C-c C-v C-t` (`org-babel-tangle`) are arguably more Org-related bindings to know by heart especially to weather through the cases where a config breaks before evil has been loaded (the cost of tinkering). The rarity at which these commands are needed may still safely keep you outside of that Emacs pinky regime. P.S.: When restarting your config, consider a literate programming approach. I've started mine less than a year ago (see [dotfiles](https://github.com/vidbina/dotfiles/tree/reorg-for-lit-prog/emacs#evil-evil)) and tinkering and commenting out sections (or recalling what the heck I was trying to do) is a lot easier now.

> ThePrimagen on YouTube has a good series, though he does have some negative thoughts on emacs (mostly legitimate criticism of how starter kits try to make it something it's not). Do you know what in particular? Because of Evil?

The only reason I have for using it is self-consistency; I tried to limit myself to only adding configuration inside of `use-package` blocks. Plain elisp would work here as far as I know. also, I'm far from an elisp sensei so anything that I write should be subject to skepticism... However, this configuration is still capable and easy to extend which is the primary idea

At this point in my emacs career I switched to Spacemacs and haven't looked back. I love having someone else figure out how it all fits together.

Heres what I do: One org file. At the beginning I have all my garbage collection, disabling the ui, initialize use package, and that all tangles into early-init.el. The next section is the "vanilla" section. Use package doesnt technically work with packages, it works with features. So everything that comes with emacs has a use package block in this section, including emacs itself. These are alphabetical. The last section is anything external that i had to install. Same as above, use package blocks are alphabetical in this section, with no exceptions. General.el needs to be loaded first since it provides a keyword for use-package to handle bindings. In this case i tangle that block to early-init.el, but in the org file it remains in its proper place. This results in a config that is easy to navigate within the org file, and the file it tangles to is also neatly organized, and my final init.el contains absolutely zero elisp that isnt within a use package declaration

The only reason not to have which-key might be if you use Embark and [set up `embark-prefix-help-command`](https://github.com/oantolin/embark/blob/5d0459d27aa7cf738b5af36cf862723a62bef955/embark.el) instead.

("for what it's worth" . "my opinion") I also think of emacs bankruptcy in the way that you do (if what I understand from what you've posted is correct: you're sick of the maintenance burden / inadequacy of your existing config and you're sure that it could be better if only you were to try it from your current perspective); I've done it myself around three times. if you think that emacs is something worth your time, you'll make it through this phase and end up with a much *much* improved emacs experience (and you will almost certainly do this again in six months / a year / 57 months / whatever)

[deleted]

Use doom emacs which sets up the basic modern editor, has extensive support for evil, and use it as a jumping point to extend with your own config. It's a very thin layer bringing your emacs from 0 to 100 and gives you structure for further extensions

> you can try to reorganize things by making modules out of parts of your config. There is a drawback to this: slower init time. not really, if you use `:defer` - most likely there won't be any slowdown > Check this there's a problem, you unconditionally `require` features there

> I feel that the value it "adds" - also stops me memorising keybindings into muscle memory, I wait for the popup, then find a command - just to be sure that it is there, then type it. You don't have to remember every key combination, but having `which-key` to cover your back (without any additional actions) is a great thing, in my opinion. If you find it too annoying - just increase the delay.

> For straight, I think there were a few packages published on github but not in elpa / melpa that I wanted to try. quelpa is package.el compatible so you don't have to turn the latter off

> It's a very thin layer are you sure you're talking about Doom?

Yes

Can only recommend using a combination of use-package and straight. Just makes your init.el so much cleaner, and so much easier to paste/reuse on other machines.

LOL, I would say you don't have to be around since the 80s to make older resources obsolete. Just look at the nodejs ecosystem or javascript language.

I am a professor in the humanities (philosophy) and I maintain a framework for Emacs (I don’t know if it rises to the level of “distro”) that is conducive to humanities work, including writing, notes, citations, a good ui, and basic programming. I’m happy to say more if you have any questions. https://github.com/Lambda-Emacs/lambda-emacs

Do you mean that I should check if those files exists in the directory first? that would be an improvement in the logic/safety, but a regression in clarity (albeit a very small regression). But since it seems like OP wants to have a local config without too many packages, this approach seems feasible and not that likely to break (I've used it this way for months with no trouble). If that assumption is wrong, please don't hesitate to explain why

btw, thanks for letting me know what the `:defer` keyword is for; I'll try it out tomorrow!

neither of those questions are dumb: 1. if there's a "standard name" for referring to "marginalia, vertico ... embark" as a group, I don't know it. MOVEC is a convenient acronym for my own mind at least. 2. Embark is a lot like a right-click menu that you have probably used from other programs. The crazy part is that it's programmable (not that you need this for it to be great) and you can use it on anything; I use it a lot to move files around, only after I realize something else: pretend you have a keybinding for `projectile-find-file`; you start typing `wi web ht` as a shorter version of `wicked-website.html`, but you realize that you accidentally copied `wicked\_website\_broken.html` into this directory earlier. no problem, but instead of typing `C-g` and then opening dired or however else you would deal with this situation you can type this: `[[[your example file]]] `embark-act` keybinding, and just move that file to where it should be - three brackets means that you already selected the file with the minibuffer (`wicked\_website\_broken.html`), you don't need to type its name again because you're using `embark-act` on that file already

[deleted]

Modularize your config; split the code you're loading into logically-separated files. Bankruptcy shouldn't happen.

> There is a drawback to this: slower init time. Why would having a bunch of modules slow down init time?

Embark offers `embark-prefix-help-command`, a variation on `prefix-help-command` (called by your `C-h` usage above) that I find better than both the default and which-key's behavior.

> So, the impression I have is that Embark let's you select and object and apply actions to that object, correct? Yes. But it can compose with other packages to do complicated things in a very pithy way. I wrote up [a few examples](https://karthinks.com/software/fifteen-ways-to-use-embark) a while ago.

There are two kinds of Emacs users: the task-focused ones who want a polished batteries-included experience, and the process-focused ones who like to tinker and try things. With some (but not much) overlap between the two. The best advice for the former is to use Doom or Centaur Emacs or Spacemacs. For the latter, which you are more inclined towards, the best advice is to learn Elisp well. It will empower you to build Emacs into a suite that suits your needs exactly, and prevent you from having to declare init "bankruptcy" again.

it definitely does seem to do so on my computer; when I decided to do this my init time went from ~2 seconds to ~2.5 seconds, so nothing huge I guess. The configuration itself didn't change other than the addition of that `module-loader.el` and breaking up everything else into files based on what made the most sense to me. Why that made init slower, I can't say.

[deleted]

I really like this idea. I haven't done a literate org config yet, so not sure I'll try that, but I like the order. Might break up the installed package section into smaller sections based on function but with packages alphabetic within section.

Thank you!

This is awesome! I'm looking through the configs now. I'm definitely adding some of this to my config. I've heard about denote and was interested in checking it out. I'm curious why you favour it over org-roam? Also, any advice on guides to getting started with LaTeX? I've been focused more on collecting things and producing for my own consumption rather than publishing, so haven't started the deep into it yet. And I love the elfeed set up! I've been trying to move more of my reading to elfeed, but keep defaulting to using a reader on my phone. I know there's a way to integrate though. Might be for next rewrite.

I feel like I'm the sort of person who if I try a vim will try to customise it too much lol. But honestly, that's good advice. Thanks. And I hope evil-org or org-evil prove useful! I haven't tried them because I've been too indecisive lol. Re literate programming: I think that might be biting off too much at once. Maybe I'll get the base and then start converting to literate programming.

Stealing acronym and definitely playing with Embark then, because that seems pretty useful.

I remember reading that and it made me curious to try it! I also remembering grabbing your function for easily tagging items in elfeed.

> I've done it myself around three times I think this will be my second? My first involved the shift to roam 2.0 and moving from helm to selectrum. I suppose this one is completing my move into the MOVEC ecosystem lol. But, eh maybe bankruptcy isn't good because I do plan on reusing a bit. Like, my org roam config is good. Most of my non-scattered org-mode too. > if you think that emacs is something worth your time, you'll make it through this phase and end up with a much much improved emacs experience Yep! At this point Emacs is my default for editing and writing notes. I still use Zotero for reading and notes related to specific articles, but if pdf-tools adds a feature like using the keyboard to select text or if I find an easy way to organise my backlog of PDFs in Emacs, I'll probably make the shift fully over lol. Then it'll just be indexing documents that is done outside Emacs.

I hear ya on biting off too much re: lit prog or vim. I've been down the rabbit hole for both for years and sometimes time just disappears to these concerns (but I tell myself it's time well spent -- maybe that's just the coping mech at work 😅). You seem to be well aware of the need to pace this the right way, so I'm sure you'll figure out what works well enough for you.

> I've heard about denote and was interested in checking it out. I'm curious why you favour it over org-roam? I like denote's simplicity and I find its code base easier to keep track of. I also don't use many of the features of org-roam and its ecosystem (e.g. I rarely rely on backlinks as opposed to search and i don't need to see a mind map of my notes). But I used to use org-roam and it is great. I'm just trying to keeps things as simple as I can. > any advice on guides to getting started with LaTeX I tend to do most everything in org-mode. But the basic setup in the writing module should work for latex writing, and I'm sure there are a ton of guides on the web for more specific issues.

Backlinks I don't use as much but I do like seeing the mind map. I've seen some cool stuff with community detection in other contexts and as my notes get bigger, I'd love to apply something like that to them. And thanks! I've been wondering whether it was worth it to learn latex vs. just work in org mode and trust it's exporting.

No one has mentioned \`org-noter\`? I started using it this year to take notes while reading papers (in pdf format) after finding out about it from a talk in the 2021 Emacs Conference. I've found having a single "[Notes.org](https://Notes.org)" file for all of the papers in a directory to be useful for handling disparate bits of information.

Haha! You're right that would useful. I've actually used it a bit, but since most of my PDFs are stored in zotero and the in-built reader is good enough, I don't use it that much. My big use for org-noter is extracting annotations I've made in Zotero to an org-mode file. Edit: also it was implicitly mentioned because it's in the configs of u/mclearc.

I never really got a good grip of Elisp, so over the years my config ended up being a bit of a lengthy mess: a bunch of \`(use-package \[..\])\` bits then a lot of random, custom things. So when I first started writing a bit of Elisp, I got this in: `emacs.d`: ```lisp ;; init file (load-file (concat user-emacs-directory "init.el")) ;; custom files (load-file (concat user-emacs-directory "spm/spm-core.el")) ``` `init.el`: ```lisp ;; load all other files (dolist (file (directory-files (concat user-emacs-directory "spm/") t "^spm-.*\.el$")) (unless (string-equal (file-name-base file) "spm-core") (load-file file))) ``` (if you're curious, `spm` are my initials so that's how I tend to prefix everything custom). which works across this file system: ``` ├── init.el ├── snippets │   ├── [a bunch of snippest] └── spm ├── spm-aws.el ├── spm-core.el ├── spm-css.el ├── spm-irc.el ├── spm-js.el ├── spm-mail.el ├── spm-misc.el ├── spm-org.el ├── spm-pass.el ├── spm-ruby.el ├── spm-work.el.gpg └── spm-yaml.el ``` It is great code? Nope. Are the categories consistent? Nope. Was it simple enough to help me move forward? Yes :)

>I use Emacs mostly for research in the humanities. Linking to PDFs, storing notes, annotating documents, and writing and editing documents. I think my key packages are pdf-tools, org mode, org-roam, org-transclusion, org-remark, and org-roam-bibtex with citar. I use straight.el + use-package to manage my packages. Others here have suggested Doom in general, but I'll suggest it for a specific reason: If you turn on the `org` (with the `+roam2` flag), `vertico`, and `biblio` modules, you get the core part of your list of packages nicely configured, without you needing to do anything other than set a few paths.

I also would recommend anyone to learn basic elisp first. It only takes a couple of hours reading the basic parts of the built-in 'An Introduction to Programming in Emacs Lisp' (C-h i m 'Emacs Lisp Intro'), which actually is a very fun thing to do. You do not have to read it all, just look over the contents (to know what is in there, so that you can look it up whenever you need it), then I would say read from the start, up to and including 'Counting: Repetition and Regexps', where you can skip some sections/chapters, that do not seem of main importance for the moment. It might seem a lot, but the chapters are generally extremely short. The one thing that is missing in the intro, is a section about edebug. So after you've read the parts of that intro, then finish with reading about [edebug](https://www.gnu.org/software/emacs/manual/html_node/elisp/Using-Edebug.html) (which should only take about 10/15 minutes). It is very simple, but very powerful. From that moment, just start hacking your own functionalities, and try to learn as much as possible from existing packages by looking up functions that already do more or less what you want (just jump to the definition of the function and inspect it, if it helps then use edebug). Also, ask questions on [Emacs stack-exchange](https://emacs.stackexchange.com/), and see if you can answer some. By following this path, I was able to write the [toc-mode](https://melpa.org/#/toc-mode) package after using Emacs for only about two weeks or so. And, in that way, I was able to contribute to packages like [calibredb](https://github.com/chenyanming/calibredb.el) and [ebib](https://github.com/joostkremers/ebib), packages I am mentioning because I think they are worth to check out, and because I am trying to point out, that there are very promising packages, that you can help to make even much more interesting. Currently, I am working on an improvement on doc-view/pdf-tools/djvu.el/[image-roll.el](https://github.com/dalanicolai/image-roll.el) which I have not yet written about, but you can have a glimpse at the (screenshot and screencast) in the issue [here](https://github.com/minad/consult/issues/625). I have learned the required elisp via the path mentioned here. (Although in the end, of course, I have tried to read some common-lisp books, and read some [SICP](https://web.mit.edu/6.001/6.037/sicp.pdf), the latter of which I can also really recommend; especially the first chapters of SICP show how (and why) elegant programming should look like). Finally, indeed I am myself an enthusiastic evil user (for which, to learn it, I would probably recommend to just start up vim and take its tutorial). Finally, I hope this is stimulating advice, and I wish you much fun (and very little frustration) learning Emacs(-lisp).