The Art Of Not Asking Why

Don't ask me why, I'll tell you anyway

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.

Auto-generated description: A mythical creature resembling a satyr with glasses is sitting cross-legged in a forest setting, holding a glowing orb in front of a laptop.
    ■

    I wrote about Harper before, but I wanted to expand now that I have it working on Kubuntu with a couple of more options.

    Harper is good in two scenarios for me: first, when I want something quick and I don’t feel like starting a browser with Grammarly in it, and second, when I write a personal email and the idea of my words going to some AI grammar bot somewhere makes my skin crawl. Otherwise, for my blog (which is public anyway) and work email (I don’t care about those) Grammarly is definitely better.

    The issue with Linux is that the makers of Harper geared it toward macOS (Homebrew) and Arch Linux, among other things. It was made for programmers by programmers, and these guys don’t bother with Ubuntu-like distros. Fair, but up until recently it meant I had to jump through hoops.

    The quick and easy route in Ubuntu distros (which is what Kubuntu is) is to use snap. I know, I know. I didn’t want to either, but since the Harper makers don’t bother with flatpak, the other option was to install a Rust environment, which is a big overkill just for an app inside Emacs I use like once a month or so or less. I don’t like snap and I don’t use it, but I made an exception here. (Edit: I actually decided to go ahead with Rust and Cargo, and explained what I did)

    Now, that snap “shortcut” is by a guy who works with Ubuntu (I think) and maintains his own package for it, so it’s on the edge channel (not stable) and seems to be a lot behind (version .49 to be exact, and Harper is currently 2.2.1!) so if Harper is your choice of grammar check, and you use it daily, I’d suggest against what I’m doing below. I’d install as needed in that case, Rust and all.

    With that disclaimer, let’s move on: sudo snap install harper --edge.

    Now in Emacs, in Linux, we want to tell it where harper is:

        (when (eq system-type 'gnu/linux)
               (add-to-list 'exec-path "/snap/harper/current/bin"))

    When tells it to add the snap path only when running Linux, since I have the same config for both macOS and Linux.

    That’s all… After that, I’ve added some of Harper’s flags, or linters. Here’s the whole code as I have it in my emacs org settings:

              (with-eval-after-load 'eglot
            (add-to-list 'eglot-server-programs
                         '(org-mode . ("harper-ls" "--stdio"))))
    
           (setq-default eglot-workspace-configuration
                      '(:harper-ls (:dialect "American" :linters (:LongSentences :json-false :AvoidCurses :json-false))))
    
    ;; Besides choosing American as the language, I also want to ignore long sentences (the main issue is that it hides other errors nested in those) and I also want harper not to tell me when it thinks something is offensive. The full list of these options is in https://writewithharper.com/docs/rules. It needs to be nested inside the :linters option.
    
           (when (eq system-type 'gnu/linux)
             (add-to-list 'exec-path "/snap/harper/current/bin"))
    
    ;; on a mac, Harper is installed via Homebrew - on Kubuntu, the best option is snap - the harper team does not do a package (flatpak) unfortunately, and I don't want to install Rust just for harper. So.. meh.  I did sudo 'snap install harper --edge' for this.
    ■

    It's official: I prefer Inkwell over Elfeed

    Last night I realized two things:

    1. I haven’t touched Elfeed in about a month
    2. I’ve been reading and interacting more with people’s posts than ever As I was looking at my Inkwell’s RSS feeds and cleaning up, I couldn’t help but notice how nice it looks:
    A reading interface displays a list of posts on the left and an RSS subscription management panel with various feeds on the right.

    And, yes, I prefer it over my list of feeds in elfeed, which are stored in an .org file - essentially lines of text with comments and tags.

    I’m pretty sure this is the opposite case for most folks who use Emacs. First, Emacs users want to use Emacs more, not less, and second, Inkwell is not available without Micro.blog1.

    But I think this is the point I’m getting at: Inkwell belongs in Micro.blog; actually, it is Micro.blog.

    When I started using Micro.blog three years ago, I considered it mostly an alternative to running my own static site with Hugo, between fixing issues with Hugo, my CSS, Netlify and understanding attempting to understand git and Magit. Yes, Micro.blog is an alternative to all of that, but it isn’t just a blogging platform; It’s a definition of a contemporary blogger.

    If you look at Micro.blog’s set of tools, you’ll see what I mean: it contains tools to keep track and post about books, movies and TV shows, private (encrypted) notes, photos and self-made video clips2, save articles and qoutes from around the internet (pocket style), automatic integration with other social media where possible - all of this around your hosted blog, complete with plugins and a theme (and let’s not forget the AI integration, if you want it and turn it on) you can tweak and take with you - your posts, media, css, everything - wherever you go.

    And Inkwell adds an important direction to this mix.

    My blogging hour in the morning now continues where I left off the night before, with saved highlights and complete articles from other people I keep track of. The integration between Inkwell and Micro.blog, where my reading turns into writing, still requires some work as the UI and some of the bugs get sorted out, but it’s there. And it’s already better and more intuitive for me than Elfeed, which takes place in its own isolated space.

    Elfeed is very good at what it does (and hopefully, what it will keep on doing, with its creator leaving Emacs), and it has been good to me. It still is. But Inkwell, Micro.blog, and my recent adventures with finding out more bloggers and learning more about the Indieweb feel like an evolution. It’s the next step of whatever I’m doing here.

    Footnotes

    1: I recall Manton borrowed the idea from a different RSS reader, but I can’t find the reference right now

    2: Finding an alternative to YouTube these days is not easy, and if you’re not trying to “build a brand” and repeat the chant of “click and subscribe,” the only semi-reliable alternative that comes to mind is PeerTube and (maybe Dailymotion?) - but Manton found a way that seem sustainable, at least for now.

    ■

    Yesterday morning, I imported an old-blog post of mine, which discusses org-id and UUIDs in org-mode. It’s a bit of a deep dive into how org-mode works. I find that I don’t do those as much anymore - probably because I mostly use Emacs “as is” with a few packages I use day to day, and my workflow has been pretty much the same (capture templates not included) for the last two years or so.

    ■

    Display images with Org-attach and org-insert-link quickly and effectively

    Suppose you have an org-mode file and want an image to appear in the buffer. The way to do that is to insert a link to the file, for example:

    [[home/username/downloads/image.png]].

    Then, you toggle inline images with C-c C-x C-v, and the image should display inside the org-mode buffer, provided the path in the link is correct. If you do this often in your notes as I do, you might as well just turn it on for the entire file with #+STARTUP: inlineimages at the top of your org file, with the rest of the options you have there; this way, images will always display when you load the file. This is all nice and good, and most of us org-mode users probably know that.

    A common use case for a full workflow like this is attaching images to your org file. You have a file in your Downloads folder, as shown in the example above, and you want to keep the image with your org file where it belongs, rather than in Downloads, where it will be lost among other files sooner or later.

    For this, as most of us know, we have org-attach (C-c C-a by default). This starts a wonderful organizational process for our files:

    1. It creates a data folder (by default) inside the folder the org-file is in if it’s not there
    2. It then gives the header (even if you don’t have one) a UUID (Universally Unique Identifier) and creates two more directories, one inside the other:
      1. The parent directory consists of the first part of the UUID
      2. The child directory consists of the rest of the UUID
    3. Lastly, the file itself will be copied into the child directory above.

    For example:

    ./data/acde070d/8c4c-4f0d-9d8a-162843c10333/someimage.png

    If you’re not used to how org-attach works, it might take some time getting used to, but it’s worth it. Images (or any file, as we will deal with soon) are kept next to the files they are associated with. Of course, org-attach is customizable, and you can change those folders and UUIDs to make them less cryptic.

    For example, my init includes this:

        (setq org-id-method 'ts)
    (setq org-attach-id-to-path-function-list 
      '(org-attach-id-ts-folder-format
        org-attach-id-uuid-folder-format))

    This tells org-mode to change the UUID to IOS date stamp format, so the folders under the data folder are dates, and tells org-mode to use that system (I wrote about this in length in my old blog; it is yet another post I need to bring over here it’s here now.).

    In my case, this creates a file reference system by date: inside the data folder, each month of the year has a folder; inside those, a folder for the day and time (down to fractions of seconds) of the attachment. The beauty of org-attach is that you’re not meant to deal with the files directly. You summon the org-attach dispatcher and tell it to go to the relevant folder (C-c C-a to bring it up, then f as the option to go to that directory).

    org-attach and displaying images inline are known to many org-mode users, but here comes the part I never realized:

    org-attach stores the link to the file you just attached inside a variable called org-stored-link, along with other links you might have grabbed, like URLs from the web (take a look with C-h v org-stored-links). And, even better, these links are added to your org-insert-link, ready to go when you insert a link to your file with C-c C-l.

    So when you have an image ready to attach to an org file, say in your Downloads folder, you could first attach it with org-attach, and then you can call it back quickly with C-c C-l. The trick is, since this is an image link (and not just any file), is not to give it a description. By default, org-mode will suggest you describe the link as the file you attached, but inline images do not work like that, and with a description, the image will just display as a file name. In other words:

    A link to an image you want to display in the org buffer should look like:

    [[file:/Home/username/downloads/someimage.jpg]]

    But any other file would look like:

    [[file:/Home/username/downloads/somefile.jpg][description]]

    By deleting the suggestion, you are effectively creating the first case, the one that is meant to display images. This is explained nicely here.

    There’s more to it. As it turns out, the variable org-attach-store-link-p is responsible for the links to these files to automatically be stored in org-insert-link (you can toggle it to change this option). This is why, when you use it, your files or images will show as [[attachment:description]], without the need for the path as specified above.

    I have years of muscle memory to undo, as I’m used to manually inserting the links with the full path for my images. I did not realize the links to the images I’ve attached are right there, ready for me to place into the buffer if I only delete the description.

    ■

    So emacs plus (through homebrew on macOS) keeps giving me this error: Invalid function: org-element-with-disabled-cache.

    Does anyone know what this is about, and why it’s happening? No issue with Emacs on Linux (same config) or when I had emacsformacos (same config)

    I believe I fixed it this morning (3/11) by removing Emacs-plus completely and reinstalling.

    1. brew uninstall emacs-plus@30
    2. brew cleanup (this removes dependencies, where I think the issue was)
    3. Delete emacs.app and emacs-client.app from /Applications (I keep forgetting to do this)
    4. brew install emacs-app (which is now emacs plus, from what I got through Homebrew)

    I also ran Brew Doctor between steps 2 and 3 and found a couple of issues I resolved, which shouldn’t be related, but you never know.

    What started this whole thing, I think, was that I wanted to try the new org-mode on top of the old org-mode. I am not too sure, but it seems like that was the problem.

    ■

    A new Emacs annoyance: org-capture: Capture abort: Invalid function: org-element-with-disabled-cache when I try to use org-capture. Fails the first time, works the second. Where did it come from and how do I get rid of it…?

    ■

    Harp is org-mode medical app for Android

    There’s the app for health-related records Irreal mentioned the other day, Harp. It’s an org-mode-centered app for Android (soon to be iOS though), which looks pretty basic at this point. You can create several profiles (for different people), and each one has a medical journal and documentation attached, along with some graphs as you accumulate data.

    It’s a good idea to have an org-mode-based health app, with all the information you need available to you quickly, protected behind encryption. The issue specific to me is that even though I have a personal Android phone, it’s my iPhone that has my medical apps (part of the Epic suite), as this is the phone I usually carry around with me. These apps already have all my health records, doctors, appointment etc.

    I’ve been playing with it a bit, and I think it’s mostly the idea of having my health records saved in org mode that makes sense, especially with the denote file convention system. My Android is also where I have signal, which I can use to share medical records with people close to me, so there’s that. It’s not ideal to carry around two phones, but I think I want to experiment for a bit.

    ■

    I think I found what crashed my Emacs on macOS

    For those of you following along, Emacs has been crashing on my Mac (but not on my Linux desktop) for a while, but it seemed too random to pinpoint. This led me into looking for the Darwin version in the Emacs build in Emacs for Mac OS (which was what I was using on my Mac), which was a couple of versions behind that of macOS itself.

    I went ahead and attempted to use Emacs Plus from Homebrew, as most people commented. I haven’t noticed much of a difference, though personally I do prefer to use Emacs from Homebrew as I do with my other packages, so I stuck with it a bit longer.

    Yesterday I encountered a stubborn crash in my journelly.org file. Journelly, which is basically a large org-file with pictures displayed in-line under some headers (you can get an idea of what Journelly is and how I use it here).

    I took a picture of the snow outside with my iPhone using Journelly, which saved it to journelly.org with the image attached. On the Mac, every time I went to open the header, Emacs crashed, time after time. I just couldn’t edit that image. In a collapsed state for the header, where the image didn’t show, it was fine. On Linux, when I tried - fine. Oh, and before you ask - I tried this with emacs -Q, and yes, it crashed every single time as well.

    The JPG image on my iPhone was a 7MB file with dimensions of 4284 x 5712. I knew from past experience that such large images slow down Emacs (on Linux too), so I shrunk it down to a 700kb file with dimensions of 604 x 640, and launched Emacs again. No problem. Everything was stable. I tried to load Emacs a few more times and it worked each time.

    This was my hunch from the beginning - that something is up with images at least on the Mac, and this is proof enough for me. I don’t know exactly at what point Emacs crashes: is it a matter of how many images the org file has? How big are they? A combination of both? But I can tell you it seems to be more about the dimensions of the image in pixels than the file size. This is fine for me, for my journal, I don’t need large high-resolution images anyway; those are uploaded and displayed on my blog and elsewhere. It seems that some folks have encountered similar issues as well, from Reddit and elsewhere.

    If you have similar issues and you’re fine with scaling down your images, a good solution is dwim-shell-commands-resize-image-in-pixels, part of the excellent dwim-shell-command package, which can quickly shrink down a large number of images from inside Emacs. I’m using it constantly.

    ■

    Switched to emacs-plus to try it again for a few days. Darwin version is now up to date. Let’s see what the differences are, if there are indeed any - and of course, if things keep crashing.

    ■

    Emacs for macOS and Darwin versions

    Regarding to Emacs crashing: AI found that my Drawin version of Emacs might be the cause. I’ve been using Emacs for Mac OS which ran darwin21.6.0 - old… (current version on macOS is 25.3.0)

    The question is, is this really the problem, or more like the AI making stuff up? It makes sense to me that an Emacs build is based on a slightly older Darwin version, though I’m not an expert. Another reason for this suspicion is that the AI assistant recommended emacs-plus without considering emacs for macOS. I know both are solid based on my own research, and I used Emacs-plus (available with Homebrew) for a while. I’ve been using Emacs for macOS for about a year, and it’s been fine until I believe I updated to the latest macOS, which everyone seems to hate, so I wouldn’t be surprised if it has to do with macOS 26 more than anything else.

    For now, I installed the latest version of Emacs for macOS, which was built on darwin23.2 - still behind, but not as bad. If this is what’s running Emacs 30.2 for so many Mac users, it further confirms my suspicion that the Darwin version is not really the issue. But maybe I’m wrong.

    I posted my question on Reddit to get some feedback, and out of curiosity, see what the Darwin version is for Emacs-plus (don’t want to install it right now). Guess we’ll see.

← Newer Posts Older Posts →