Stopping to think
I have 16 minutes left in my lunch break and don’t have time to write this in a way that makes sense. But I want to put this here to remind myself to try to tie together:
- What Mike Hall wrote in Because You Can about the tendency to shave off keystrokes and end up over-automating something, when sometimes it’s better to preserve enough friction in your process to give you a chance to slow down and think. I used to actually enter things directly into all my topic journals and individual log files in one Markdown folder. Even when all I had at the moment was a phone! I still have all those files, one each for found music, books to read, movies to see, and dozens of other areas. But then I adopted the Daily Notes idea. Drafts was extremely good and fast at capturing ideas, quotes, links, and any kind of text-based ephemera into one note per day. And now I have 3,958 draft blobs in the Drafts inbox and the individual text files are neglected and poorer for it.
- What Dave Gauer wrote in Making sense of it all: wrap-ups about doing weekly and/or monthly retrospectives on your daily notes, journals, obsessive logs, whatever. I feel like tedious, manually-created wrap-ups are the secret decoder key to making notes and logs into something valuable. Whether I’ve relied on Roam, TiddlyWiki, Obsidian, Logseq, or org-mode to “tie everything together”, it’s still the same thing: hoping technology will make sense of everything without me having to do any work.
- Looking back at this list of questions to ask yourself in a yearly review, and finding the text file where I answered most of those questions at the end of 2017. In there were tons of events I’d forgotten about and advice I gave to my future self, also forgotten. But the 2017 text file was all manually created — certainly copied and pasted from other sources, but not auto-generated in a dynamic list from tags sprinkled across Daily Notes. And because the minutiae was sifted out and the best parts rose to the top, it’s one of the most important records I have.
A haphazard Doom upgrade
Last night, just before midnight, I thought I would do a “quick” upgrade of Doom Emacs on the M1 Max MacBook, since it had been well over a year since I’d upgraded. It’s a dumb choice for someone who knows, say, what a bad idea it is to do a deployment to prod on a Friday afternoon. This is the same thing at home. Here’s what I did, and I’m not saying any of it is recommended, but it’s what got things working again.
It all started when I did this in Terminal:
doom upgrade
And got:
> Upgrading Doom Emacs...
> Cleaning .elc files
- No elc files to clean
x There was an unexpected error
Message: File is missing
Error: (file-missing "Opening input file" "No such file or directory" "/Users/phil/.emacs.d/core/packages.el")
Backtrace:
etc.
So I googled that and found on the Doom Discourse site:
Breaking change on b9933e663771
A heads up to Doom users:
doom upgrade
will break itself when updating Doom past b9933e6
A-ha!
So I tried these lines in The workaround section:
cd ~/.emacs.d
git reset --hard a9866e37e45b43785116ef474c8cd6aa9b5185dd
git pull origin master
doom sync -u
And got this:
x There was an unexpected runtime error
Message: Symbol's function definition is void
Details: (straight-recipes-nongnu-elpa-retrieve)
Backtrace:
etc.
I thought maybe I needed to follow the advice here:
https://github.com/doomemacs/doomemacs/issues/4950
You need to manually upgrade straight :
So I did what they suggested:
cd ~/.emacs.d
rm -r .local/straight/repos/straight.el
./bin/doom sync -up
That seemed to go mostly ok but I got a handful of warnings about branches being ahead/behind, so I went with the options it suggested to follow when you’re “unsure”.
And then at the end it said:
! Wrote extended straight log to ~/.emacs.d/.local/state/logs/cli.doom.230627002937.13605.error
! Script was abruptly aborted, leaving Doom in an incomplete state!
- Run 'doom sync' to repair it.
So I ran:
doom sync
and that seemed to go ok.
And then I tried to manually upgrade Doom again:
cd ~/.emacs.d
git reset --hard a9866e37e45b43785116ef474c8cd6aa9b5185dd
git pull origin master
doom sync -u
Got a few more prompts to “pick this if unsure”, followed those, and got:
! Wrote extended straight log to ~/.emacs.d/.local/state/logs/cli.doom.230627003634.17287.error
! Script was abruptly aborted, leaving Doom in an incomplete state!
- Run 'doom sync' to repair it.
So I again did:
doom sync
Ran Emacs and got some errors like this. You know you’re in trouble when you can’t even get a clean launch:
Error (doom-after-init-hook): Error running hook "doom-modeline-mode" because: (void-variable doom-modeline-mode-alist)
Ran this:
doom doctor
And oh lord, lots of problems, starting with:
> Checking your Emacs version...
! Emacs 27 is supported, but consider upgrading to 28.1
Emacs 28.1 is better supported, faster, and more stable. Plus, Doom
will drop 27.x support sometime mid-2022.
Ok, then! Might as well upgrade Emacs, too.
brew update
brew upgrade
doom sync
And it ran forever, updating tons of things I probably will never use, and then I launched Emacs and thank heaven it worked ok. Whew. Now I’m on Emacs 28.2 and Doom 3.0.0.
And this is something I do for fun?
Blindness and note-taking
As if I didn’t need another thing to worry about regarding where to keep notes (Markdown, org-mode, paper, etc.), I’m adding a new layer: What if I go blind someday?
I’m not even kidding here. I’m already legally blind in my right eye because of having a congenital cataract removed shortly after I was born. Back then, we were years away from lens implants being commonplace, so my eye just never learned to do much of anything and now it’s only useful for peripheral vision. I was taught from before I could speak to protect the left eye at all costs. That eye seems to be doing overall fine, and I’m going through all the life milestones that come to a 52-year-old person. First came distance eyeglasses, reading glasses, and now progressives.
But someday that eye may get a lot worse, or I may get injured somehow in a way that leaves me truly without usable sight. What happens to all my carefully curated Markdown and org-mode files then? How will I use a computer with any kind of speed? I hope to not find out anytime soon, but I’m curious, and so I find things like this:
EmacsConf 2019 - 08 - How a Completely Blind Manager/Dev Uses Emacs Every Day - Parham Doustdar
(Text version, in org-mode!)
Of course tons of people in this situation adapt and figure out ways to use their hardware and software for work and play. But it makes me wonder, for now:
- Is Markdown more blind-friendly because it’s less powerful and there are so many apps that understand it?
- Is org-mode the better bet because it’s so transmutable?
- Which corner am I painting myself info if something happens?
- All this stuff is text anyway, so does it even matter?
- What file-naming convention is the easiest to hear instead of see?
- How granular should my text files be? Small, single-purpose files, or sprawling with tons of headlines?
Jumping between org-journal entries
I go hot and cold on org-journal, and when I get into it I build up quite a history in it, especially after settling on the monthly file format (like 2023-06.org
) as the one that fits my brain the best. I like how even if you’re not in Emacs, it’s easy to scroll through and scan the days with your eyes, and the entry metadata makes for a nice header:
#+TITLE: 2022 February
* Friday, 04 February 2022
:PROPERTIES:
:CREATED: 2022-02-04
:END:
Worked on-site. Ate lunch w/Josh and Kathy.
* Sunday, 06 February 2022
:PROPERTIES:
:CREATED: 2022-02-06
:END:
Finally got `consult-ripgrep` working in Doom Emacs for org-mode files thanks to help from Jack.
Washed more dishes. Watched part of an old Psych with SH. Ate a small lunch of leftover falafel and 1/2 a bun.
But I didn’t feel nimble in it when I was in Emacs. You can do consult-org-heading
to jump to any heading when you’re in a monthly org-journal file (or any org-mode file), but if you have subheadings, you’re going to wade through those, too. And you can navigate through headings in other ways in org-mode, but the nicest org-journal way is with org-journal-next-entry
(C-n
) and org-journal-previous-entry
(C-p
), because it jumps you back and forth by whole days, switches you between files when necessary, and collapses all but the one day you’re looking at:
#+TITLE: 2022 February
* Friday, 04 February 2022
:PROPERTIES:
:CREATED: 2022-02-04
:END:
Worked on-site. Ate lunch w/Josh and Kathy.
* Sunday, 06 February 2022 ...
* Monday, 07 February 2022 ...
I still don’t have a good convention for what goes in org-journal entries vs. daybook.org
, events.org
, or Day One, but every little bit of friction I can remove from Emacs helps. Using org-journal to browse around its own entries as nature intended also helps me step away from the crazy idea of including all the org-journal files in org-agenda.
beorg: subfolders, searching, init file
Should be doing chores, but I’m having hotbrain about beorg, the org-mode app for iOS:
- According to this forum comment from Matthew Kennard, the developer, you can sync subfolders (even in Dropbox) if you add
(set! sync-subfolders #t)
to yourinit.org
. He says it’s experimental, so be careful. Still, wow. - There are a ton of options to group and sort search results that I didn’t know about.
- You can create an
init.org
file to customize advanced settings. You can look at thelibrary.org
file to find out what’s possible to customize.
Org-mode event logging
I’m again feeling that pull to figure out The One True Way of logging past events, appointments, meet-ups, gatherings, walks, etc., all in one place, and probably in org-mode. I don’t know if it’s a ghost/demon that makes me think this because I in fact need to do a “real” project and don’t want to commit, or if it’s a legitimate need.
But especially with this year’s conversion to a paper calendar, I don’t have Google Calendar to search for past stuff. I like the idea of having things in org-mode because the date stamps are built in and the Agenda comes alive when you use them.
I’ve tried this before with a daybook.org
file or org-journal, so this isn’t new ground—just a fixation brought back to the front of my brain. I want a format that’s nice to look at when I’m in Emacs, but also not too ugly to edit and search when I’m not around my laptop. I don’t know. Just writing this down to work through things.