Miscellaneous Emacs configuration
6 minutes read
I’ve been spending a bit of time getting my Emacs configuration up-to-date, cutting down on bloat, and reducing package usage. Here’s how it went:
Setting up presentations
One of the things I wanted to streamline was setting up presentations directly from Emacs. I’ve tried a couple of methods, and here’s a quick rundown of what worked best for me.
Setting up a LaTeX environment
Org-mode continues to be one of Emacs’ most powerful tools. One thing I discovered recently is the Org-beamer export feature, which lets you create presentations directly from Org files. It’s pretty neat since you can structure your slides just like an outline. It’s like writing your slides in markdown but with the full power of Org-mode’s features. All you need to do is use a couple of #+ directives, and the export to LaTeX will handle the rest.
Note that this needs the following set up:
pandoc- I obtained it from the AUR since I use Arch (BTW). Installation steps vary depending on the GNU+Linux distribution and OS.TeXLive- it’s possible to use the system package on Archlinux, but I’ve setup a local installation. Here’s how I did it:
# this typically needs gunzip installed
I added the Texlive installation to the Emacs path because I do not like these scripts “polluting” my fish suggestions 🙄. Anyways, a simple
did the job for me.
I ended up using this setup for a few talks, and honestly, it’s super handy. The presentation is completely text-based, so you can tweak content as easily as changing a heading. I also love that you can embed code blocks with results in your slides if you’re doing a technical talk, which looks great.
Org-beamer
The LaTeX backend for Org-beamer is solid and works wonders with the LaTeX environment mentioned above. YMMV.
Here’s a minimal setup for using Org-beamer:
#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: Madrid
You can specify themes, colors, and the layout you want. A couple of tweaks like this can go a long way to make your presentation look clean without needing to dive into too many customization details.
Here’s what my setup looks like. Note that I’ve set this in my Emacs configuration because I’ll mostly follow similar settings across presentations.
To get Org-Beamer to work, all you need to do is add a #+STARTUP: beamer to the (top of) the file you want to export.
You can then export your slides to Beamer PDF and open it in any PDF viewer (or even your browser). Sweet. Who needs PowerPoint office suites?!
Via Org-reveal and RevealJS
On the other hand, if you’re more into web-based presentations, Org-reveal comes to the rescue. It exports your Org-mode files to HTML and integrates seamlessly with Reveal.js, giving you smooth transitions and interactive slides.
The process is pretty straightforward: just make sure you’ve got the necessary tools installed (like the ox-reveal package). Once you’ve set up Org-reveal, your Org files can become fully interactive web presentations.
The best part? You can embed JavaScript, custom themes, and even interactive elements like quizzes and polls. I prefer this setup for non-technical presentations, where I want some snazzy effects and a more polished, web-based result.
Call me biased, but I prefer this over the previously mentioned Beamer solution. Who doesn’t like some pizzazz??
Add something like this to the Org file that you want to export:
#+REVEAL_JS: t
#+REVEAL_THEME: solarized
#+REVEAL_TRANSITIONS: zoom
And here are my settings:
There are lots of themes and transitions available out of the box, and you can always tweak them as needed.
Switching to Elpaca from Straight
I’ve also been taking a closer look at package management in Emacs. After spending a long time using Straight.el, I decided to give Elpaca a try, mostly due to its simplicity and speed. Straight.el has been great, but it can sometimes feel like overkill, especially if you’re just looking for a lightweight, fast way to manage packages.
Elpaca is built to be much leaner, and it doesn’t try to do too much. It’s focused on performance, which, for me, is a huge deal. I noticed a slight performance boost after switching, and the configuration is super simple compared to what I had with Straight.el.
Here’s how you set it up:
(I’ve plagiarised this from the elpaca README).
;; Install use-package support
Then, I just migrated my existing packages over to Elpaca. The process was smooth and didn’t require a complete rework of my setup. So far, everything’s been fast, and the management overhead is much lower.
For migrating packages available on GitHub from Straight to Elpaca:
- (use-package emacs-everywhere
- :straight (:type git :host github :repo "tecosaur/emacs-everywhere")
+ (use-package emacs-everywhere
+ :ensure '(emacs-everywhere :host github :repo "tecosaur/emacs-everywhere")
If you’re looking to simplify your package management and reduce some of the complexity that comes with more feature-rich solutions like Straight, Elpaca is definitely worth checking out.
This is where the fun begins.
Anakin, Ep 3, Revenge of the Sith (2005)
You need a mail indexer such as mu installed. You also need a mailbox synchroniser such as mbsync:
gnutls is likely installed by default on your GNU+Linux distribution. Then you need an Application Password for authenticating to GMail. You can obtain one from the Google Accounts page. Simply search for “App Password” in the search field and create an app password. Store the App password securely for we’ll need it later.
We now need to configure Emacs and mbsync.
Emacs
Add this to your configuration:
Replace USERNAME and NAME appropriately.
But wait? Where are the actual Gmail credentials? Surely they must be stored somewhere?
To answer that question, add this to the ~/.authinfo file: Create the file if it doesn’t exist.
Obviously replace abcd bcde cdef defg with the Application Password that you set previously.
Now encrypt this file:
This will create a ~/.authinfo.gpg file that stores the App Password.
Do the same thing for your Gmail password.
echo <password> > .passwd
gpg -c .passwd
rm .passwd
Create the directory where you want to store your mail. I’ve stored mine in ~/.mail.
We’re almost there. Now all that’s left is to configure mbsync (aka isync) and fetch the mail…
Create ~/.mbsyncrc with the following content:
IMAPStore gmail-remote
Host imap.gmail.com
SSLType IMAPS
AuthMechs LOGIN
User <USERNAME>@gmail.com
PassCmd "gpg -dq --for-your-eyes-only ~/.passwd.gpg"
MaildirStore gmail-local
Path ~/.mail/
Inbox ~/.mail/INBOX
Subfolders Verbatim
Channel gmail
Master :gmail-remote:
Slave :gmail-local:
Create Both
Expunge Both
Patterns * !"[Gmail]/All Mail" !"[Gmail]/Important" !"[Gmail]/Starred" !"[Gmail]/Bin"
SyncState *
Obviously replace <USERNAME>@gmail.com with your email address.
Finally, let’s create initialise the mail index and fetch the mail:
mu init --maildir=$HOME/.mail --my-address='<USERNAME>@gmail.com'
mu index
When you open Emacs the next time, a simple mu4e-update-index will display all the email you have received.
RSS
I’m not quite sure how often (or even if) I’ll use this functionality, but I’ve set up an RSS reader inside Emacs. This was simple to do, and I’ve just plagarised DT’s configuration.
Fin
All in all, this update to my Emacs setup has been pretty satisfying. I’ve cut down on unnecessary packages, streamlined my workflow for creating presentations, and improved performance. The best part is that it’s still flexible enough for me to jump into new tools or adjust things as I need them.
If you’re looking to clean up your own configuration or try out some of the things I mentioned, I’d say go for it. Emacs is an ongoing adventure, and it’s always fun to explore new ways of improving the experience. Happy hacking!