Einar's blog
26 nov. 2022

Elfeed with useful scripts

Elfeed is an RSS feed reader package for GNU Emacs. RSS is a standard for getting content like podcasts, video channels from LBRY and Youtube, twitter feeds, blog entries, news articles etc from the web without using a browser. Before I started using elfeed, I used Newsboat, a terminal program, as my RSS reader. I was inspired by Napoleon Wils0n to add scripts to Newsboat so I could launch videos from RSS feeds directly in mpv or download them with youtube-dl (and later yt-dlp). After I started using Emacs, I wanted to try to integrate most of my computing into it and I looked at the two built in feed readers before trying the highly recommended elfeed package. I liked it, so the next step was to find a way to get the same functionality I had in Newsboat in elfeed.

I don't know Elisp well enough to script this myself yet, so I looked online. I read up on the documentation for elfeed on GitHub and also found some inspiration on Reddit that I tweaked to make some elisp scripts to be able to hit m if I want to watch a video in mpv and M if I want to download it with yt-dlp to my "Nedlastinger" (Downloads in Norwegian) folder. I tried a couple of different solutions before I was able to get what I wanted. The suggestion from Reddit was to use start-process to launch an external process with the url from the entry as its argument. That worked well with mpv. For yt-dlp that was less successful and I also wanted to change directory to ~/Nedlastinger before launching the yt-dlp process so I read up on how to run shell-commands asyncronously and used that functionality instead. I also made certain that any shell command run asyncronously doesn't display a new window. (A "window" is a split within an Emacs "frame" (an X11 window) in Emacs parlance. Emacs is from before the Macintosh introduced the desktop metaphor's now common vocabulary (that Microsoft later copied in Windows), so it uses its own vocab for these concepts.) The reason why there are two scripts for each functionality is that I can use those keyboard shortucts both inside the view where you show the specific entry and in the view where you see all entries while one is selected.

;; Dette gjør at Async Shell Command ikke vises hver gang man kjører en shell kommando med & fra inne i Emacs 
(add-to-list 'display-buffer-alist
  (cons "\\*Async Shell Command\\*.*" (cons #'display-buffer-no-window nil)))

;; Gir meg muligheten til å bruke m i elfeed for å åpne en rss entry i mpv
(defun browse-url-mpv (url &optional single)
  (start-process "mpv" "*mpv*" "mpv" url))

(defun elfeed-show-mpv-open (&optional use-generic-p)
  "open with mpv"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-mpv))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-mpv-open (&optional use-generic-p)
  "open with mpv"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-mpv))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "m") 'elfeed-show-mpv-open)
(define-key elfeed-search-mode-map (kbd "m") 'elfeed-search-mpv-open)

;; Gir meg muligheten til å bruke M i elfeed for å åpne en rss entry i yt-dlp
(defun browse-url-ytdlp (url &optional single)
  (shell-command (concat "cd ~/Nedlastinger &&" "yt-dlp -f 'bestvideo[height<=720]+bestaudio/best' " url " &")))

(defun elfeed-show-ytdlp-open (&optional use-generic-p)
  "open with ytdlp"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-ytdlp))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-ytdlp-open (&optional use-generic-p)
  "open with ytdlp"
  (interactive "P")
  (let ((browse-url-browser-function #'browse-url-ytdlp))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "M") 'elfeed-show-ytdlp-open)
(define-key elfeed-search-mode-map (kbd "M") 'elfeed-search-ytdlp-open)

Those scripts worked fine for video channels from LBRY and Youtube, but not for podcasts which use an enclosure url to give the url to the actual episode's video or audio while the general url field in the RSS entry is used for show notes. I tried searching for variables within elfeed with the built in self-documenting features of Emacs, but did not fully understand how to find the enclosure url. After some searching aorund the internet, I found a way to get the enclosure-url and recycled most of my previous code again with the new url to make two functions making it possible for me to listen/watch a podcast with mpv by hitting P and downloading it with yt-dlp with K. I only implemented this for one of the two views.

;; Gir meg muligheten til å bruke P i elfeed for å åpne en podcast (enclosure) i mpv
(defun elfeed-show-play-enclosure (enclosure-index)
  (interactive (list (elfeed--enclosure-maybe-prompt-index elfeed-show-entry)))
  (let ((url (car
	      (elt
	       (elfeed-entry-enclosures elfeed-show-entry)
	       (- enclosure-index 1)))))
    (start-process "mpv" "*mpv*" "mpv" url)))

(define-key elfeed-show-mode-map (kbd "P") 'elfeed-show-play-enclosure)

;; Gir meg muligheten til å bruke K i elfeed for å laste ned en podcast (enclosure) med yt-dlp
(defun elfeed-show-dl-enclosure (enclosure-index)
  (interactive (list (elfeed--enclosure-maybe-prompt-index elfeed-show-entry)))
  (let ((url (car
	      (elt
	       (elfeed-entry-enclosures elfeed-show-entry)
	       (- enclosure-index 1)))))
    (shell-command (concat "cd ~/Nedlastinger &&" "yt-dlp -f 'bestvideo[height<=720]+bestaudio/best' " url " &"))))

(define-key elfeed-show-mode-map (kbd "K") 'elfeed-show-dl-enclosure)

I have set my default browser with my environment variables to Firefox and even though I like Emacs' built in browser eww a lot for text-based content with the occasional picture, I want to keep Firefox as my default browser for now. However, when I read an RSS entry in elfeed and it does not supply the full blog post, it is nice to stay within Emacs and read the linked blog post with eww instead of launching a heavy external browser. So I had to make two functions for the two view modes for that as well. So for those RSS feeds that do not supply the full content, I just hit B and the content opens up in eww. There is built in functionality to open the linked content in the default browser by hitting b in elfeed, so whenever I want or need to open the content in Firefox, I just hit b. For some content that is dependent on JavaScript or is full of media, I sometimes use that built in function, but usually, I use B instead.

;; Gir meg muligheten til å bruk B i elfeed for å åpne en rss entry i eww
(defun elfeed-show-eww-open (&optional use-generic-p)
  "open with eww"
  (interactive "P")
  (let ((browse-url-browser-function #'eww-browse-url))
    (elfeed-show-visit use-generic-p)))

(defun elfeed-search-eww-open (&optional use-generic-p)
  "open with eww"
  (interactive "P")
  (let ((browse-url-browser-function #'eww-browse-url))
    (elfeed-search-browse-url use-generic-p)))

(define-key elfeed-show-mode-map (kbd "B") 'elfeed-show-eww-open)
(define-key elfeed-search-mode-map (kbd "B") 'elfeed-search-eww-open)

Comparing my present elfeed setup with my former Newsboat setup, one thing that is much nicer with these scripts and elfeed is that I don't have to use an external program for podcasts. Newsboat comes with podboat which is intended for use as a podcatcher after you have qued up the content within Newsboat. That process always felt cumbersome and I actually didn't use it because of that. With elfeed and a few scripts, I have all kinds of feeds within the one reader and use a few different keyboard shortcuts to get everything done that I want. Another nice thing with elfeed is its search functionality which is very powerful.

My Emacs journey is still in its infancy, but the more I delve into Emacs, the more I like it. It's powerful, personal and pleasant. Emacs extends the hackability of GNU/Linux further by allowing you to tweak not only your DE or WM through configuration and shell scripts, but also the program you do most of your tasks inside. Integrating more functionality into Emacs means less friction and context switching between different tasks. Thus far, I have only integrated RSS reader, email, pdf document creation (org mode with latex export to pdf), blogging (org mode and org-static-blog), some web browsing (Firefox is still my default browser, but I use eww more and more), note-taking in org mode (I used to use vim and markdown) and of course general text-editing.

It's interesting how much faster for instance navigating around my emails is in mu4e within Emacs than in Thunderbird which was my previous email program. I think the reason is that Emacs is both text and keybord-centric (while also allowing for mouse use if you are so inclined). Elfeed has also become more useful than Newsboat used to be for me since I now also use it for podcasts. The hackability of Emacs means you can add functionality you want or customize things to your own preferences easily. Emacs also uses less system resources than other programs while doing more. Fewer resources means less power use and longer battery life on laptops. You can save money and possibly also CO2 emissions if your electicity is produced in environmentally unfriendly ways.

I see Emacs as the ultimate step in my gradual move towards less resource usage for my computing that started when I switched from Mac OS X to GNU/Linux in 2011, moved to a light-weight desktop environment (LXDE and later LXQt), then to even lighter weight window managers, gradually switched some GUI programs with terminal programs and scripts and then in the end the gradual integration of many tasks into Emacs. (I did this mainly out of curiosity, but I have reaped other rewards like less resource usage and more freedom as well.) If you see Emacs as only a text editor, then it is more resource hungry than vim (but less than VSCode), but if you see it as what it is: an integrated, hackable computing environment, then it is less resource hungry than the combination of programs you would use to do the same tasks. It is also the ultimate expression of the FSF's ideal of empowering users through the use of free software. I am definitively going to delve deeper into Emacs in the months to come.

27 aug. 2022

Vim vs Emacs for fast text editing

vimvsemacs.jpg

Introduction

I used vim for 2 years and got it into my muscle memory before my Emacs curiosity led me to try out GNU Emacs in the spring of 2022. Many people say vim is the faster text editor, but Emacs is wonderfully extensible. After having used both, I don't think vim is faster than Emacs, so I am going to show how many consecutive key presses you need to accomplish some common tasks in both and compare. Of course, you can use evil-mode in Emacs and edit text the vim way, but I am comparing the usual non-evil default keybindings of Emacs with the defaults in vim. There is also the common halftruth about crazy key chords in Emacs contra simple one-key presses in vim. This is true for many workflows, but not so much for actual text editing. For text editing, the keyboard shortcuts in Emacs are usually just a modifier key plus an alphanumeric key.

I believe that pressing two keys at once takes the same amount of time as pressing one key. I call both "a keypress". On the other hand, pressing three keys consecutively takes three times longer than pressing three keys at once because you have to depress one key, lift up your finger, then depress the next key, lift your finger and then depress the next key and lift your finger. Therefore the actual speed of editing is determined by the number of consecutive keypresses to get something done, not the total number of keys depressed. As an example, I often press C-c C-, s (Ctrl-C Ctrl-, s) to insert a code block in org mode which is three consecutive key presses and a total of four keys (I hold Ctrl down from the time I start pressing c until I have finished pressing ,). This could have been faster if it involved fewer consecutive keypresses even with the same amount of totalt keys, like for instance the keypress C-M-S-, (Ctrl-Alt-Shift-,) which is just one keypress, but also four total keys. My point is that when thinking about the speed of editing, it is the number of consecutive keypresses that matter, not how many keys you press at once (although fewer is less akward for the hand).

In this blog post, I will use Emacs symbols for keybindings in Emacs where C = Ctrl, M = Meta (Alt or press and release Esc), S = Shift and s = super (Windows/Tux/Purism/Apple Commmand Key/…). Emacs keybindings are generally written with a dash when pressed together and with a space in between when consecutive, for instance M-b C-p means Alt and b pressed at the same time and then Ctrl and p pressed at the same time. When the same modifier key is used for two consecutive key presses, it does not have to be released like the example above with C-c C-, s shows. When writing about Vim, I will use Esc for Escape and use no space between consecutive keypresses which is the usual vim way, for exampel 2gj for the three consecutive keypresses 2, g and j. All other glyphs just represent themselves.

Comparison of keypresses for common editing tasks

Before starting to write anything in vim, you have to press i (or a or o etc). In Emacs, you just start writing. That's one keypress for vim and zero for Emacs. After you have written a sentence, maybe you want to move back and do an edit. Let's say you want to move to the start of the sentence you just wrote and add something in front of the first sentence. In vim you would press Esc to get to normal mode and then 0 to move to the start of the line (not necessarily the line you see on screen, but the start of the chunk of text since the last newline character) and then you would have to press i. In Emacs, you would press C-a (or M-a if the sentence is longer than one visual line) and start to write. In vim, you would need three consecutive key presses and in Emacs one before you started to write your new first sentence. After you have written your new sentence, maybe you want to go to the end of your paragraph and add something. In vim, you would press Esc, then A and then start to write. In Emacs, you would press C-} and then start to write. Again, vim has two consecutive keypresses and Emacs has one before writing.

Maybe we want to move two visual lines up and correct the misspelling of the word "icnonsequently" next. The word is two visual lines up, but starts four columns (four letters) to the left of where we are now. In vim, you would press Esc to get to normal mode, then 2gk (that is not one keypress, but three consecutive key presses) and then 3h (two key presses), then d, l, i and c, which is 1 + 3 + 2 + 1 + 1 + 1 + 1 = 10 consecutive key presses. In Emacs, you would press C-2 C-p (or C-p C-p) (two consecutive key presses to move up two visual lines since Emacs works on those), then C-2 C-b, then C-t (to use the function transpose chars with the cursor at the third letter), ie 5 consecutive key presses.

I could probably think of more examples, but the point is that for most edits, Emacs demands fewer consecutive key presses than vim. You can check out Emacs Rocks' episode 3 and 4 where Emacs is faster than vim for a couple of Vim golf tasks. Protesilaos Stavrou has also made a video where he shows off Emacs Macros for solving Vim Golf tasks. I think most of these are faster than vim as well. There are probably more examples floating around the internet if you care to find them.

How can vim be slower than Emacs? Everyone think it is the opposite…

The reason why we get more consecutive key presses and spend more time to get from one point to another and start writing in vim is because of the modal editing. Since we constantly have to hit Esc to get to normal mode before moving around and then hit a, o, i, r, c, A, O, C or I before actually getting to start typing our text, we generally need two or at least one (when combining movement and getting into insert mode like with A) more consecutive keypresses for moving around and starting to write in vim than in Emacs. There are also more functions in Emacs for editing text, many of which are bound to simple key combos like the function transpose-chars that we used above which further saves keypresses compared to manually deleting a character, moving and then adding the same carachter one letter later in the word. Even if you count the total number of keys depressed and disregard that it is faster to press two keys at once than to press the same two keys after each other, Emacs usually ends up with fewer total number of keys pressed for doing the same edits.

Modal editing, as shown above, is slower since you have to go in and out of modes. In addition, it is very unlike any workflow most of us have ever used before, which means that it takes more time to learn text editing in vim than to learn text editing in Emacs. As someone who has spent time learning both vim and Emacs, I found it a much steeper learning curve to learn vim for text editing. Emacs can also do everything else, so you can continue to learn Emacs after your muscle memory has adjusted to its text editing workflow and that is the reason why many people think Emacs is hard to learn, but for text editing, it is actually much easier to learn than vim since the way you edit text in Emacs is less weird.

Both vim and Emacs have good tutorials that you should spend some time with when trying them out for the first time, but for vim, I felt like I had to go back to the tutorial a lot of times before I really mastered the concepts of modal editing. When I finally made my own vim cheat sheet for my Norwegian keyboard layout and hung it on the wall underneath my screen, I finally started to get its keyboard shortcuts into my muscle memory. (I published that cheat sheet here, but realized I did not actually have the right to base my sheet on the model I used since it was not published under a free culture license, so I had to remove it.) With Emacs, I felt that the text editing keyboard shortcuts were more intuitive and easier to learn and remember, although I have made a cheat sheet that I plan to laminate soon and hang where my vim cheat sheet used to hang before.

Ok, so Emacs is faster for text editing, but what about…

Editing remotely

Emacs has built in functionality called TRAMP which lets you edit files on remote servers through SSH from the comfort of your own, well-configured Emacs. If you use Vim on the remote server through SSH, you get the configuration of vim from the server which is probably vanilla vim which might feel foreign if you have spent some time editing your vim configuration. Or you could spend time transferring your config over to the server. There is nothing stopping you from running terminal Emacs from the remote server through SSH if you absolutely must, but you get the same disadvantage as with a remote vim that you do not get to use your own configuration. TRAMP is the elegant solution to this problem.

Lightweigh footprint

Vim is usually used in the terminal (even though gVim exists) and Emacs is usually used as an X program (with Wayland support probably landing in version 29). This makes typical vim more minimal than typical Emacs. This is true. However, Emacs works perfectly well in a terminal as well. Both vim and Emacs started out as terminal line editors (ed and Teco) in the 1970s that over time morphed into the programs we know and love today, so even if they both have GTK X11 variants, the terminal is where they both grew up. You loose the ability to have different fonts in different modes and you loose the ability to show pictures inside buffers, but othwerise, Emacs runs really well in a terminal. The X clipboard needs a package for integration into Emacs if you use it in the terminal (just like vim's registers do not correspond with the X clipboard without some configuration except if you have installed gVim and use terminal vim based on it) or you could use C-S-c and C-S-v which most terminals use today to copy and paste (as in vim) if you don't mind changing your habits. If you use many custom keybindings including C-m or C-i, you probably want to rebind those to something else since they have special meaning in a terminal. Or you could configure your terminal to treat those keys differently.

All that being said, Emacs is heavier than vim because it includes a lot of built in functionality that vim does not have. This might be good or it might be bad depending on your point of view. I recently spent some time in Emacs on the tty of my Raspberry Pi 3 B+ and surfed the web with Emacs' built in eww browser to check something in the Debian Wiki quickly before continuing to configure my minimal Debian system. I checked "free -m" from Emacs' ANSI term (one of the many built in terminal emulators inside Emacs) and I used 128 MB of RAM with three buffers open: eww, ANSI term and a scratch buffer. You could use W3M and vim alternating to achieve the same, but I think the few extra MBs of RAM and SSD space Emacs takes is worth it to get to do it all within one program (even when used from a tty).

Emacs might be fast at editing, but it starts slowly

Emacs can be slow to start if you have a lot of stuff in your config. The recommended way to avoid this (both for terminal use and graphical use) is to use Emacs as a server that starts up with either a systemd unit or other init script or you can start it with your Window Manager or Desktop Environment at startup. Whenever you then want to use Emacs, you should use "emacsclient" to open a window to the already running Emacs server process. This makes startup of your Emacs window ("frame" in Emacs terminology) or terminal window very fast. I have bound "emacsclient -c -n" to Super+F6 in my Sway config to fast get a new window with Emacs whenever I need one.

Ergonomics

This is where vim shines, especially if you rebind Esc to Caps Lock which many people recommend for vim use. Modal editing means that you can do all your edits with keyboard shortcuts that are generally just Esc to get to Normal mode and then one alphanumeric key for each command, unlike in Emacs where you have to use one or more modifiers plus an alphanumeric key to get the same thing done. In text editing, the key chords are simple in Emacs, but for other workflows, there are some crazy keychords. When you learn that you can keep Ctrl depressed if you have two consecutive keypresses which contain it, that helps. Over time, most key chords you use often become muscle memory and if you want to rebind crazy keybindings you use often, that is easy to do. Many recommend rebinding Ctrl to Caps Lock for Emacs use since then you have ctrl in a more natural position for you left pinky. I think ergonomics is the real reason why many prefer vim. It is not faster to press more consecutive keypresses even if there are fewer keys in each, but it is more ergonomic. It is probably also the reason some Emacs users use evil mode and that it exists in the first place. Since Emacs is an Elisp interpreter, you can do things like that, but using Emacs keybindings in vim is not possible since vim isn't as hackable as Emacs.

Unix philosophy

Emacs does one thing well and that is to interpret Emacs Lisp. It does not matter if you edit text, chat on IRC, read and reply to email or look at PDFs while taking notes in Org Mode, it is all done by executing Emacs Lisp. Many Emacs users use it as a program that integrates many tasks they do into one cohesive workflow. Even if Emacs can become all-encompassing, it does not have to. You can just use it as a text editor if you want. Today, vim both interprets VimScript and edits text and NeoVim does the same plus interprets Lua and is embeddable. Emacs just interprets Emacs Lisp. Maybe you need a bit of mental gymnastics to get any of these programs to fit the "a small program that does one thing well" philosophy?

Conclusion

The myth that Emacs is good at anything except text editing is a myth, not a fact. It is a slightly faster text editor than vim and it is much easier to learn to edit text in because you do not have to grasp the concept of modal editing. Even so, how many key presses you need to get things done and how much time it takes might be less important to you than other factors when you choose your text editor, especially since most time is probably spent thinking. How inspired you feel by the software might be more important to you than the speed of editing. Maybe you prefer to separate different functionality into different programs and configure all of them to use vim binding or maybe you like to integrate them all into a hypermoldable, super-hackable Emacs Lisp interpreter. Or maybe it is important for you to use the same software as your colleagues, friends or fellow students to be able to share their workflow tweaks and take part in a shared culture?

I think both (Neo)vim and Emacs are good choices for investing some time into learning since they both have strong communities that will make sure they will be around for fitfy years more (unlike some editors, both FOSS and non-free, that are developed by companies or individuals without communtiy participation and may be abondoned at any time, like Atom exemplified recently). Both editors demand a bit of configuration which is a slightly different approach than many of the newer editors that are more ready out of the box experiences, but might not be as flexible to adjust to your workflow (as opposed to you adjusting to theirs). In the end, you choose the tools that work the best for you. Just don't lie and say you use vim because it is faster when you haven't even given Emacs the chance to convince you otherwise.

06 aug. 2022

Emacs text-editing cheat sheet

Update august 14th 2022: I moved searching from editing to movement and tidied some explanations.

I have made a text-editing cheat sheet for Emacs. My plan is to print and laminate it and hang it on my wall underneath my screen above my standing desk where I formerly had my vim cheat sheet. I find that quick access at a place I naturally look helps me learn and remember keyboard shortcuts. The more I look at them, the easier they are to remember and the more I use them, the more they become part of my muscle memory.

There are of course a lot more functionality in Emacs with keybindings specific to their particular modes (in Emacs a mode is a group of functionality for a particular workflow or task unlike in vim), but even though Emacs can do anything else as well, it is also a really good text editor. This cheat sheet is only for the text-editing parts of Emacs. There are probably more keyboard commands than I am aware of that should/could have been included. I will probably revise and update this blog post in the future.

I have only used Emacs for a few months by now, but its text-editing abilities and speed has won me over from vim. I originally just wanted to test Emacs to give it a chance, but I am now convinced I am going to continue to use it. (Neo)vim is also a great text editor, but it is just not as good as Emacs in my opinion. I will write more about why I think this in a future blog post. You are of course free to disagree with me and use whatever text editor you like.

I made this cheat sheet the Emacs way in Org Mode. Underneath, you see a downloadable png of the cheat sheet. The original .org-file is also available for you. Maybe you want a light version instead of the dark png, maybe you want it to be high resolution or maybe you want to include more keychords. As always, my content is licensed as CC BY SA 4.0, so feel free to do whatever you want to the files as long as you attribute me and share your remixes under the same license.

Emacs_text-editing_cheat_sheet.png
04 aug. 2022

I now use org-static-blog to create this blog

I have moved from WordPress to Hugo to nothing and now on to org-static-blog to create this blog. One reason to move to org-static-blog is that I have switched from using vim to using GNU Emacs as my text editor. When I used Hugo, I wrote my blog posts in vim and Hugo made it into a bunch of static pages that I uploaded to my webserver. Hugo has many features, like themes, RSS feeds, tags etc and is very practical to use if you use markdown on a regular basis. Since I was a vim user, my idea was to use markdown for everything and use Hugo for my website and pandoc to convert my .md files into LaTex-styled PDFs, LaTex Beamer presentation PDFs, ODTs and the occasional .docx when needed. I converted most of my older documents to .md and worked like this for a while. Then my Emacs curiosity got the better of me, and this spring, I started dipping my feet into Emacs.

I soon realised the power of Org Mode and that it could replace my former markdown workflow with practical features like automatic tables, lots of easy to use keyboard shortcuts for creating the .org markup syntax and very easy exporting to all the aforementioned formats plus many more. Not to mention that it is also a calendaring and todo-system, that it includes a REPL for any programming language you care for that you can use for literate programming, that it can also be used for journaling, a personal note taking system with reverse-linking etc. Naturally, I have been looking for a way to write my blog posts in Org Mode as well. Many people use Hugo and just convert their .org files to .md files with the emacs package ox-hugo. To me, this seems to be one step more than what I would actually like to do and what is actually necessary. After the war in Ukraine started, I left my website with just a static HTML page, but I have recently wanted to get back into blogging. I had started to work on making a program to make a static site from a bunch of .org files when I discovered the Emacs package org-static-blog that did the same. My plan with my program was to make it first in Bash Shell since I am more familiar with that language and then move it to Elisp for easy integration with Emacs later. Org-static-blog made all that work unneccessary.

Org-static-blog makes a nice index page with a blog-roll of the newest pages, an archive page and an RSS feed. You may also add links to other static pages you would like to include. If you use the tags feature, you can also get RSS feeds for each tag. Personally, I want to just keep things simple for now and have opted out of that feature. To make a new post, you just write an .org file with a title and date and optionally also a description and file tags metadata on the top and then just write your content. Each .org-file becomes a blog post. You can also use org-static-blog-create-new-post to automatically make that document with the correct tags for you which is nice for people like me that have yet to start using metadata heavily in Org files and would enjoy a helping hand with that.

When you are ready to publish your blog, you just run org-static-blog-publish in Emacs, and org-static-blog spits out all the HTML-files you need in your chosen export folder. To make the site look nice, you should make a style.css file that you put into your export folder and link to it in your header as described in the README. There are no themes, but the author links to his own website's Git repo where you can grab his style.css and tweak it to your own liking. As a dark mode lover that also likes to keep things simple, I have opted for a simple black and white look with the occasional light blue for links. The CSS styling is set it and forget it, so after the initial tweak, you are good to go. Just org-static-blog-publish and upload your static files to your website and there you go.

org-static-blog.png

The advantage of using a static site generator over something dynamic is faster load times and easier access to content for non-JavaScript enabled users. Not having unecessary JavaScript running just to show some content that is easily accessible without it also saves power for the site visitors which is good both for the environment and their economy and especially important when Europe is going through an energy crisis caused by Putin's invasion of Ukraine and energy war with Europe.

24 feb. 2022

In support of Ukraine

In support of freedom, democracy and self-determination for Ukraine.

Flag_of_Ukraine.jpg
Other posts
All blog content is licensed under the Creative Commons Attribution-ShareAlike 4.0.