Posts tagged "emacs"
If you have (or make) a keyboard which is fully programmable, it’s likely that
you will spend a lot of time messing about with programming it: not because you
need to, but just because you can. My little Ferris Sweep has been through
several iterations of layouts this year. I know me, so I would bet no money at
all on this being true, but I think that I might be getting close to the perfect
layout for me with this keyboard. In the process, I have also stopped using
in Emacs in favour of the delightful meow.
It will surprise no-one (least of all me) that I am back in the arms of Doom Emacs again (not for the first time), after playing around for a while with a configuration built from scratch. It was a really fun experiment again, and I had a chance to play around with some of the packages that weren’t (at the time) included in Doom Emacs. Once again, I learned a bit more about configuring packages, and also thought about what features I really need. It is tempting with Doom to just enable all the things. That isn’t a bad approach exactly, but it does make it more difficult to figure out where there are conflicts and inevitably it can make things a bit slower.
I’ve been here before, but I find myself back here again. I think that many people who start off with one of the big frameworks (like Spacemacs or Doom Emacs) eventually circle around to thinking, “hey, why don’t I just build my own Emacs config that includes the best bits of Spacemacs/Doom?”. Usually, that is followed some time later (as happened in my case last time), by the realization that those frameworks are really well crafted, and getting anything like that degree of polish and sleekness yourself is very difficult without basically replicating the entirety of those projects. However, I’m playing with configuring from scratch again, just for kicks.
When I’m working in Emacs, I like to have some visual separation between
different workspaces (which roughly equate to different projects). Previously, I
was using Doom Emacs’ workspaces feature, which uses persp-mode. My initial
reason for disabling workspaces was because I found that
projectile-switch-project didn’t work properly with it enabled, but I also
thought it would be interesting to see what I could set up using built-in Emacs
functions. What I ended up using was Emacs’ built-in tab-bar.
My Emacs tweaking tends to go in waves. I keep an eye on the Emacs subreddit and the Doom Discord channel on a fairly regular basis, but I try not to jump on every cool new package I see discussed there. Every now and again though, I see something interesting which coincides with an itch to tinker with Emacs, and away I go… This time, it was reading discussions about a constellation of relatively new packages concerned with incrementally narrowing lists (and other related functions) that caught my eye. This sounds very niche, but for many people (me included) being presented with a list of things and being able to type to incrementally narrow the list and then select something is a core part of the Emacs UI. Since I use Doom, and it offers you an easy way to choose either Ivy or Helm, I had been using Ivy, for the sake of easy configuration. Both are fine packages, but having tried both, I preferred Ivy’s more minimal interface, and the fact that it used the minibuffer rather than a buffer for completions. However, it — and the related packages, Counsel and Swiper — are somewhat complex and difficult to get to grips with. I was also not using all the features that they provided, so was curious if I would enjoy using something even simpler. That’s why I tried out Selectrum.
One of the delightful and surprising things about Emacs, as you get to know it better, is the depth of customisation which is available. Emacs can be a completely different editor for different people and for different purposes. Being able to tweak things on the fly and try them out before you commit to them, or even as a temporary fix to solve the particular problem you have right now, is empowering. The more you delve into it and try things out, the better you understand what is possible and the more comfortable you get with writing elisp. Recently I discovered the ‘advice’ system in Emacs, and now every problem looks like a situation for some well-placed advice!
Emacs is really the gift that keeps giving. It has now been about 4 months since
I started using
org-mode to manage all my todos, and it has been working
terrifically well for me. Despite having lots of different projects to juggle at
the moment, I continue to feel more or less on top of things — or at least, I
know how much stuff I haven’t been able to get to yet! The best thing about
org-mode is that you can expand and develop your system as your
needs change. You don’t need to set up a complex system at the start, nor do you
need to make the whole system complex if only one part of it needs extra
structure. It’s all very flexible. I’ve made a couple of tweaks recently, and
also started adapting my system of keeping notes which I thought might be
interesting for other Emacs users and the Emacs-curious.
After I posted about using org-mode, Jack Baty wondered (somewhat
tongue-in-cheek) how I managed with keeping only some of my tasks in
org-mode. Actually, it wasn’t really a problem copying tasks across from
OmniFocus to enter into my journal entry for the day. However, I inevitably
started wondering whether I might be able to go the whole hog and use only
org-mode for tasks. Would I lose track of things? Could I capture tasks
efficiently when away from my computer before I forgot about them? Would the
world explode into chaos? Well, if you don’t feel like reading further, the
answers to those questions are No, Yes, and Quite Probably, But Not Because I’m
I’ve been back a week from a work trip, and — as I often do after a busy period — I’ve been taking stock of what I need to do next and refining my systems a bit. Cynics might argue that this is either procrastination or yak shaving (and they wouldn’t be entirely wrong), but when I have been at full stretch at work I do find it helpful to have a period of sorting out the mess that I had to let accumulate, to tie up loose ends and to plan the next bit of work.
I am spending more and more of my time in Emacs for all things, so I wanted to refine both my agenda and journalling setup.
The inevitable wheel of Emacs life has circled back again, and — as the title suggests — I have moved back to Doom Emacs. When I last wrote about my Emacs configuration, I was trying to move away from frameworks (including Doom), and to set up my own configuration from scratch. It was a really fun process, and I think a necessary one for me to really understand how to configure and use Emacs, and the way that all the moving parts fitted together. However, I have recently overhauled my whole command line setup (again… more on this later), so I got curious to try out Doom again. It was always a great project, but in the time since I last used it Henrik Lissner has polished and improved it even more to the point where it is a really fast, slick and easy to use framework.
I’ve been having a lot of fun with Emacs since I last wrote about it. I’m gradually starting to get comfortable with it, by doing as much as possible of my text editing (as well as other kinds of tasks) in Emacs. For example, I had to write some new lectures this Semester, and used Org mode to write them, using the built-in converter to make a Beamer PDF. I used the ability to include another file in the header to set up all the stuff needed to use the Metropolis Beamer theme, which I could then easily include in each lecture file. It was a delightful way to work. I split my frame into the org file for the lecture, a
dired buffer showing the image files I wanted to include so that I could easily copy the filename into my lecture file (just move the cursor to the line in
dired and hit
w to copy the filename so you can yank it in your file), and a
docview window showing the generated PDF file.
I feel like this post could be subtitled “For real this time”. Let’s just say that it’s certainly not my first time down an Emacs rabbit hole. I’ve used Spacemacs, then given up because I found it hard to maintain and fix small issues that arose. Then I moved to Doom Emacs, and liked it a lot. It was more compact and less monolithic than Spacemacs, but it still required more Emacs knowledge than I had at the time to understand how all the working parts fitted together. Then I went back to Neovim, and so the bouncing between Vim and Emacs cycle began again. This time, something struck me: what if I was approaching Emacs in the wrong way, trying to make it into something it isn’t, namely Vim? What if I actually took the time to learn how to do things the Emacs Way, and built up my configuration from scratch, adding only what I needed and understood? It was a crazy idea, but it might just work…
It has been about 18 months since I started using Spacemacs, and I am still constantly learning wondrous new things about it, and about Emacs more generally. I go through waves of tinkering and learning, but I find myself using Spacemacs for more and more things. I’ve had a recent tinkering bout — partly inspired by some helpful resources — so I thought it was probably worth documenting what I’ve done here for anyone interested, and so that I remind myself what I did when I inevitably forget a few months down the line! This is going to be quite a long article, so whether you are an Emacs fan, or just Emacs-curious, you might want to get a drink of your choice and settle back.
Regular readers will know that when it comes to tinkering with text editors, I can’t leave well enough alone. I’ve used many different editors over the years, but have kept returning at various intervals to Vim. I like Vim a lot, and despite its various inconveniences, I find myself missing modal editing and the ease with which you can move around and edit text when I am using other editors.