Emacs org-mode
Welcome to the Emacs org-mode category.
You can subscribe to this category only via RSS!
I am working on restoring some of my related posts from my old blog, so keep checking here for new content.
A bit of a teaser:
This bit of dwim-shell-command magic works nicely:
(defun jtr/dwim-shell-command-pandoc-org-to-docx ()
"uses pandoc to convert an org file to docx using a template docx file. The docx template file is stored in my synced notes folder"
(interactive)
(dwim-shell-command-on-marked-files
"converting from org to docx"
"pandoc -s '<<f>>' -o '<<fne>>.docx' --reference-doc ~/Sync/Notes/custom-reference.docx"
:utils "pandoc"))
Why I use Denote?
When I mentioned Denote again a couple of days ago, Omar commented that whenever someone mentions using Denote or org-roam, he’s curious to know if that person tried vanilla org-mode first, without additional packages.
I get it. After all, I’ve been resisting the whole Zettelkasten bandwagon and org-roam with it for a while, keeping the same opinion about org-roam Omar seems to have about Denote (I’m speculating here, of course). In general, I don’t like the idea of Doom Emacs or Spacemacs for the same reasons. Denote, for some reason, never registered this way. I liked it from day one.
As I was answering his question and he asked for more details, I thought it might make a good post. So here we are.
Not a whole lot changed for me since I first looked into Denote. I still mostly use it for my blog posts (like the one you’re reading right now) and my info notes, which mostly contain technical how-tos to myself and to a lesser degree, some records and memos, like a list of equipment in my home or who’s who at work. At this point, I also have a third, personal folder with notes only on my Linux computer as well, which mostly contain “supplemental” notes as I call them to journal entries I want to expand on in private (I use my work iPhone with Journelly, which does a fantastic job, but I don’t trust Apple or any cloud service for that matter with my private stuff).
It has been slow progress, but I’ve improved my usability with Denote, which I recently enhanced further after having the pleasure of talking to Prot 1:1 in one of his online tutoring sessions (always a pleasure, and highly recommended if you ask me).
The main philosophy behind Denote is something I’ve been in agreement with for a long time, before I started using it, or Emacs, or even got familiar with Linux: the idea of how to date and rename files. I’ve never agreed with the American way of writing dates, and I always prefer the ISO format: yyyymmdd followed by hhmm. To me, this is how things should be organized. So when Denote came around with Prot explaining that this is how he sees files should be organized - date, followed by keywords, and then a title - it just clicked.
You can extend this file-naming scheme to all your personal files if you’d like (at least all the files you visit with Dired), and I’m in the process of doing exactly that. Because the renaming function is built into Denote, it’s easy to stay concise and avoid mistakes (for example, renaming one file 20260124 something, and then another 2026124, emitting the 0 for January). While it’s true you could easily do that without Denote, to me, this core piece was like a sign that said, “Hey, look at this, this guy is building a package that is based on something that makes sense, check it out.”
Tags are another important part of Denote. Org-mode has tags built into headers, which works, but the headers, to me, are a bit too specific to need them. For the most part, I can get the level of information I need through the header itself, and I use tags to associate a certain header with a person - but even that is not useful, as I often work with too many people for the tags to really mean anything. Meanwhile, it’s the files themselves that need tags: certain workflows are similar, but are tagged to work for different operating systems (say, how to set my work VPN on Linux vs on my Mac), or maybe I have a naming convention for different departments at work, and I want to tag the relevant departments.
I didn’t always break my different workflows and notes into files. In the past, I had one org file as a wiki: a single file with many headers explaining workflows and procedures. I often had errors there. It was one big file that I often opened and edited, so I had syncing issues, headers that got mixed up, etc. The other problem I had with the wiki was logical: at times, a certain subheader would fit under two different headers, and I would have a hard time deciding where to place something. Headers work as categories, while tags work as ,well, tags. If we take the VPN example from before, I could put my VPN instructions under “networking,” “security,” or “remote work,” but not all. I don’t have this problem with Denote.
Another, more recent skill I started using with Denote is its metadata and search features. Meta notes work as an index of other files, where I can have one file with a dynamic list (updated whenever the file is loaded) of live links to other files with the same tag or other regex I use. Meanwhile, searching with Denote using denote-grep (something I learned recently) shows a list of all the files matching my search in collapsible form, making it easy to find what I need. I can use one of many denote-query forms to filter those results even further, and of course, there’s denote-consult, which, well, if you know consult, you know what it does, and it’s excellent.
Finding stuff is a central issue for anyone keeping notes, no matter what system they use. Denote supplies me with the best tools I’ve seen for this job. It’s true that many of these tools are already available in Emacs and in org-mode. Denote doesn’t alter these existing options; rather, it builds on them. In fact, that’s a big part of Denote: the way its commands are constructed borrows from what Emacs already does, so if you’re familiar with one, you intuitively know what the same thing would do inside Denote.
Another example of the above is the org files you create with Denote. You can use Denote directly with a capture template, and each file is created with file tags that make sense if you use org-mode: #-title, #+date and #+filetags, which denote changes automatically as you rename files with it. These work together with additional options I include in my notes, such as #+STARTUP: inlineimages. In a Markdown export, such as this very post you’re reading now, Emacs knows to ignore these org-mode only options, so I don’t need to clean them out when I’m ready to post. It’s a nice touch that already exists in vanilla org-mode, but with the added benefits of Denote, like having my post tagged, dated, and easily found in a search alongside the rest of my Denote files in the future.
There are definitely more features of Denote I don’t use, or use enough (blacklinks, which I believe are more of a recent introduction, is one of them), but as I stated above, this is a process. I learn more every week, and as my notes collection increases, so does my understanding of how to use Denote in a way that works for me.
Spent the last day and a half on and off figuring out how to use pandoc to make my org-mode files in pretty, readable docx files, including tables. It was a challenge, but it’s worth it. The key is to use a reference doc and to know how to use it. Need to expend on that.
Reflection on my Emacs experience
A couple of days ago I found out org-mode capture sun menus can handle additional nested menus. To recap quickly here (see more details in the link), this means that you’d have the main menu for capture templates, which will lead to additional templates menus, and that menu can keep leading to more and more menus. I am not sure how many levels of these templates we can have, but “more than enough” is a good enough answer for me.
As I was writing the post above, I went back to my old blog and reviewed two of my older, Emacs-usage-defining posts, and added them to this blog: Org-mode in files and Submenus in org-mode capture.
Those of you who enjoy reading about the Emacs experience from a user perspective (especially someone who started out without a programming background) might want to give those a read, in the order mentioned above. Beyond explaining these crucial org-mode methods (and in my opinion, crucial to use Emacs in general), these describe the struggle and the learning process of, well, how to Emacs correctly: from realizing an option exists (of course it exists, it’s Emacs), through asking the right questions, to finding the information and implementing the solution.
I’ve spent a couple of hours re-reading and revising these posts, and reached a conclusion that many of you who are reading this over their RSS feed in Emacs would probably agree with. We, Emacs users who blog, have a critical role in the Emacs ecosystem: we provide others with ideas and questions to ask, which can later be directed to official channels, the manual, and brainstorming answers.
As I mentioned a couple of times throughout the lifetime of my blog (this one and the old one): Emacs is not just a program, it’s a lifestyle.
org-mode capture: menu inside a menu
Over the weekend, I modified my org-capture templates again. I was curious to see if I could create a second-level menu in org-mode capture under my already existing menu items - and as it turns out, it’s possible, and also pretty straightforward. Here’s the start of the setting (keep in mind it’s not complete, don’t just copy-paste this):
(setq org-capture-templates
(quote (
("w" "work")
("wt" "work-ticket")
("wta" "work-ticket department A" entry
(file "~/Sync/Work/department A.org") (file "~/Sync/Templates/temp-ticket.org"):prepend t)
This will result in the following:
Select a capture template
===========================
[w]... work...
then:
Select a capture template
===========================
[wt]... work ticket...
then:
Select a capture template
===========================
[wta] work-ticket department A
I should explain this further, probably first explaining why I need such a complicated system of menus within menus, but every time I sit down to explain I run out of time. I wanted to put it out there first, and I’ll come around to explain it soon, hopefully.
I like the DU command in Dired
I had fun using the du command in Emacs this morning (that’s what I do when I don’t sleep well; judge away).
In Linux (and macOS), the DU command (I believe it stands for Disk Usage) is usually used to figure out what folders take up space on your hard drive.
While different GUI tools exist, they are not useful on encrypted drives on Linux, as they show the encrypted blocks instead of the directories, which don’t really tell you much (you could probably run those with escalated permissions, but I didn’t try).
For a gamer like me, it’s useful to see which games take up the most space. Here’s an example with a few useful flags, in the command line:
du -hs ~/.steam/steam/steamapps/common/* | sort -h
Shows me the following:
4.0K /home/jtr/.steam/steam/steamapps/common/Steam.dll
76K /home/jtr/.steam/steam/steamapps/common/Steam Controller Configs
100K /home/jtr/.steam/steam/steamapps/common/SteamLinuxRuntime
248M /home/jtr/.steam/steam/steamapps/common/Steamworks Shared
657M /home/jtr/.steam/steam/steamapps/common/SteamLinuxRuntime_soldier
776M /home/jtr/.steam/steam/steamapps/common/SteamLinuxRuntime_sniper
1.4G /home/jtr/.steam/steam/steamapps/common/Proton - Experimental
3.4G /home/jtr/.steam/steam/steamapps/common/Deep Rock Survivor
3.5G /home/jtr/.steam/steam/steamapps/common/Deep Rock Galactic
11G /home/jtr/.steam/steam/steamapps/common/Hades II
21G /home/jtr/.steam/steam/steamapps/common/Yakuza Kiwami
82G /home/jtr/.steam/steam/steamapps/common/Space Marine 2
132G /home/jtr/.steam/steam/steamapps/common/Helldivers 2
Some of the Steam-related components are not games, but… Helldivers 2 takes how much space?? Anyway.
A quick review of the options I used:
-hs for human readable (shows space in G for gigabyte and M for megabyte instead of writing in kilobytes) and summary (shows the top directory only)
~/.steam/steam/steamapps/common/* for the target path (this is where Steam stores the games in Linux, at least in Debian distros)
| to pipe the du command it into another command to read it better, in this case:
sort -h the sort command, which will sort it nicely again by order in human format. We need this last part if we want to see the directory in order, with the biggest one at the bottom.
Some places recommend using sort -hr, the additional r for reverse, which means in this case we will see the biggest directory at the top of the list. I don’t need it, because I want to see the biggest folder at the bottom, near the command line, which is where I’m going to focus next.
In Emacs, this command is easier use and works better thanks to Dired. Find a folder, mark it (m) in dired, and run dired-do-shell-command (!) and follow up with du -hs.
But since we’re in Emacs, and we might want to work with the results as text, we could use dired-do-async-shell-command (&). This will place the output in a temporary buffer we can work with (so we can save it to a text file, for example, with C-x C-w).
And here’s another thing I didn’t know: you can run these commands in Dired on multiple directories. Just mark several directories in Dired, and the resulting buffer will give you a list of all the directories you’ve marked. If you have this saved as a text buffer, it’s pretty easy to work withthe results (for example, save it as an org file and add headers telling you what you want to do with each directory).
By the way, even though it’s somewhat redundant with Dired’s default listing of files, you can also add the a option for du in this case ( for all) to display the files in the directories you’re viewing. This is useful in cases like the above, where you’re already working with the du command in Emacs and interested in looking at individual files as well, not just directories. Of course, you can just go in and list the files in Dired and open another Dired buffer with another directory listing files by size… this is Emacs, you have many ways to do whatever you want.
I think I’m going back to clocking in and out of sub-tasks, even though I said I wouldn’t. It’s easier not to, but the end result, I think, is messier, and I can’t get the clock reports right… on the other hand, it’s kind of an overkill. 🤔
Rediscovering org-clone-subtree-with-time-shift: if you have regular meetings, this is the function for you.
Create a Meeting event with everything you need (Zoom links, place for notes, tags, etc) and clone it X number of times. Emacs will ask you for the frequency. You now have X meetings ready.
Handling project in Emacs - the 2025 version
Ever since I’ve decided to move away from iCloud1, I’ve had a hard time syncing my org files with Beorg, which is how I worked with org-mode tasks on my iPhone. Frustrated, I looked into a solution that I should have revisited long ago: Plain Org.
I got Plain Org before I heard of Journelly, so it’s not just because I’m a fan of Álvaro’s work. At the time, I was just looking for an app that could read org files and lay out my projects in a nice, clear way. As it turns out, Plain Org does more than that - by doing less.
Compared to Beorg, Plain Org is very minimal. But it works with Synctrain (Syncthing for iOS), it accesses my org files on my iPhone quickly and easily, and it lets me make quick modifications when needed. For everything else, there’s Emacs. And that’s what I seem to have forgotten.
It took me a while to reconnect with the understanding that my iPhone is not the place to manage tasks and projects, despite what everyone around me seems to think, whether it’s my workplace with its Microsoft Office suite or Apple with its ever-improving Notes and Reminders. As I mentioned earlier, other apps look and work great, as long as you play by their rules. As soon as you need something customized for your needs, you’re out of luck. I can play by the rules to an extent, but not when it comes to how I think and work. I guess I had to write it out here to arrive at that conclusion again, and surprise surprise, things are working out again.
What followed was reorganizing all my org files. A deep system cleaning that was much overdue. First, I archived many of them in my archive folder. Next, I went into my projects org file itself and archived a big chunk of projects that should have been completed and/or put away a long time ago. The trick was to remind myself that archiving is not the same as throwing away something: it’s simply putting it out of sight. It’s a simple rule: if it just sits there staring me in the face for more than a week, it needs to be archived. If I need to work on it again, I can put it back: org-refile is a powerful tool. I can always go into my archive folder, which is not a part of my agenda on purpose, and search through it with occur or consult-grep.
Speaking of my org-agenda: I got rid of scheduled TODO tasks, and I’m trying to keep it this way.
The kind of work I do today is 100% projects. There’s no such thing as a simple task; if it’s simple, it gets delegated. This means each project header, which is signified by the keyword ACTIVE, has somewhere between 5 to 20 subheaders: meetings, additional tickets, purchases, notes, emails, documents attached with org-attach, you name it.
Making these subheaders into scheduled TODO items quickly overwhelms my agenda and hurts motivation. Besides, I was stuck in the habit of always having a next-action item for every single thing, so many of those TODOs just ended up being something like “Follow Up” or “Reminder.” That’s a waste. A project is already marked with “ACTIVE” for a reason, after all. I know I need to follow up on something, that’s the entire point. The other thing is that the project header (the parent header) should be the header I work with. It’s where I keep my logbook notes (C-c C-z), and where I clock in and out. I used to do this for each subtask, but then I had to think about which notes go under which task, and it made it harder to follow up later, as I had to search across different tasks containing different fragments of notes. It’s too much running in circles. Now I just look at my list of projects, pick one to work on, and start a clock (C-c C-x C-i). When I’m done, I clock out (C-c C-x C-i) and write a few notes about what I did.
I still use subheaders when I need to save something (like an email, a ticket, or meeting notes), or when I work on something that takes more than half an hour on its own.
My work environment is a hectic mess these days, and Emacs is the only thing that is flexible enough (as always) to deal with… everything. The amount of productivity and communication apps people at work around me use is staggering, but they all work in the browser, need to be online, and don’t allow to customize things.
I need to be able to organize my head in Emacs. This is so important that I’m considering enforcing a small unofficial “break” during the day when I just sit down and clean up my projects and actually do some stuff. Otherwise I’ll be stuck all day just running after emails.
Footnotes
1 Many folks use iCloud and are happy with it, so why do I make my life difficult? The two technical reasons are my Linux desktop, which I use to access some of my org files, and my Android, which is more like a backup device to capture some notes. Another reason is the lack of control of iCloud: it works most of the time, but when it doesn’t, it really messed me up. It just stays stuck and doesn’t sync for whatever reason, and in case of a conflict, iCloud “decides” which file is the right one and overwrites whatever was there before. When I lost some work because of this recently, it was the last straw. Syncthing would always create a conflict file, where I can run Diff in emacs and quickly decide what I want to keep. It also has a built-in file versioning in its folders, which has saved me a couple of times in the past.
There’s also the tinfoil hat: I’m grumpy guy who yells at clouds. To put simply, I don’t trust Apple to store my personal and private files. After viewing their transperency report I was surprised to find out they share data with law enforcement 70-80 percent of the time. I just don’t like the “think of the kids” PG approach.
If you’ve been using Emacs on macOS and iOS for a while, you probably know Álvaro Ramírez, the maker of Journelly and dwim-shell-command. I’m a fan of both.
Turns out Álvaro has a sponsorship page on GitHub. If you benefit from his work and look for a way to help out, this is it!