Newest posts:

An apology to Protesilaos Stavrou and David Wilson

A while back, I read an Emacs News post by Sacha Chua and saw that the Emacs carnival for the month was about mistakes done early in one's Emacs journey. I read this one of the last days of the month, late in the evening, and thought I would chime in before the next theme in the carnival. So I wrote and posted a blog post fast, late at night.

Later when I reread what I had written, I realised it did not say what I was trying to say and instead insulted two brilliant contributers to the Emacs community, so I deleted the post. I have felt bad about it ever since, and I feel that I owe the people I insulted an apology.

What I was trying to say was that I should have spent more time early on to read the built-in documentation in Emacs. If I looked more into the built-in documentation of variables, functions, keyboard shortcuts and read a bit more in the manual, it would have given me a more comprehensive understanding of how Emacs works. I learned a lot by watching videos, but in retrospect, I wish I had also found the time to read up more.

Unfortunately, the blog post read as if I was saying that I should not have watched as many videos by Protesilaos Stavrou and David Wilson as I did, which wasn't really what I meant. I apologise to David Wilson and Protesilaous Stavrou!

Before I started using Emacs, I watched a video by Protesilaos Stavrou who told me that Emacs is an integrated environment that can be tailored to the user's need with less context switching than using [Neo]Vim plus CLI and TUI programs which was what I did at the time. Emacs seemed like something I would like to try, and I have Protesilaos to thank for getting the right frame of mind of what Emacs is even before starting to try it out!

When I started trying out Emacs, I did the Emacs tutorial and then I watched videos by Protesilaos Stavrou and David Wilson that guided me forward in my journey. David Wilson's "Emacs from scratch" series taught me a lot about configuring Emacs early on and Prot's videos on dired, eww, elfeed, diary and calendar taught me about specific modes. These videos made the confusing early days of using Emacs a lot less confusing and a lot more enjoyable!

I have continued to watch their videos and they have given me a lot of useful information and lots of ideas of workflows, modes to explore and settings to use to make Emacs both more efficient and more pleasant to use. I have also enjoyed David Wilson's SystemCrafters videos on Guix. I have learned a lot by watching their videos and I am very grateful for their work!

The Genius of Lisp

I have just read the book The Genius of Lisp by Cees de Groot. It was a very interesting read. The book tells the history of the Lisp programming language from 1958 to today and also how Lisp, as one of the earliest high level programming languages, has influenced other programming languages over the years. It also goes into the technical details of how Lisp dialects were implemented and the differences between them. And it explains the mathematical groundwork by Alonso Church and Alan Turing for the Lambda calculus, and how John McCarthy used it to build his language.

The technical details are well explained and as easy to follow as they possibly might be. There is example code in IBM 704 Assembly with explanations, practical implementation examples in JavaScript that is easy for present-day programmers to follow, explanations in pseudocode and of course lots of code examples in various Lisp dialects. The early chapters on the mathematical underpinnings of lambda calculus and the foundational work for Lisp and its practical implementation gave me a proper understanding of it even if my mathematical knowledge is very limited.

For me personally, I felt that after reading the book, I now have a better understanding of the different dialects of Lisp, who created them and for what purpose. I knew about some of the dialects and some of their traits, but I learned a lot more about them. For instance, I did not know that Common Lisp is a thoroughly object oriented language and this surprised me.

Although I knew about the previous AI hype with "expert systems" and the AI winter that coincided with the economic downturn in the late 1980s, the book enlightened me with more details and more about its consequences for the AI language Lisp. We are fast heading into a new AI winter now since the LLM providers have unsustainable business models, but I think the consequences for Python will be less dire since its growth in popularity started long before the present LLM craze and it is less closely tied to AI research than Lisp was. (I bet on Python when I studied at the only Norwegian University or College that taught it instead of Java as their first language and since then, its popularity has only grown, from at that time being less used than Java and C#, but now being the second most used language after JavaScript/TypeScript according to Stack Overflow Survey.)

Reading The Genius of Lisp has strengthened my belief in Lisp as a brilliant programming language worth exploring further. It is not on the top 20 list of programming languages now, but it is powerful and elegant with its homoiconic s-expressions for both code and data. Learning more about the different dialects through the book also further convinced me of my previously somewhat uninformed hunch that Clojure and Scheme are Lisps I should look into further. (I am already a Guix user thanks to David Wilson's brilliant SystemCrafter videos, but I haven't had the time to delve deeper into Scheme.) My first meeting with Lisp was in Emacs, and I will continue to play with Emacs Lisp as well.

All in all, it was a good read and I highly recommend this book to people interested in programming, computer history and the mathematical underpinnings of functional programming, the Lambda calculus. Some previous knowledge of JavaScript is useful for understanding the implementation of Lisp functions in the early chapters.

Dunk Dunk

Ro! 🇳🇴

Speed improvement hack for dired with EWW

I have used EWW in Emacs for some of my browsing for a while and it does the job very well unless browsing single page applications or other sites that do not send HTML unless you run JavaScript. Thank you Lars Magne Ingebrigtsen for making EWW! Hitting R filters out all the noise for a really pleasant reading experience. It is good to browse within Emacs with no context switching in a keyboard-driven way.

(Apropos the joys of context switching: When I am a bit tired, I use Emacs keybindings everywhere. Tap-to-click is naturally off on my laptops to prevent insanity. I am often able to "help" my students a lot within just a few seconds of random keybindings and clicking everywhere on their laptops. It is really good for students to learn patience and tolerance towards people unable to handle computers. They need that for their user support class and future work in the IT industry.)

When Joshua Blaise wrote about his eww setup and use, I read it with interest and stole most of his ideas for my own config. The important one for this little hack is that I set up URLs with endings like .mp3, .mp4, .m4v, .mkv etc to launch in mpv when browsing to them. This makes watching videos and listening to audio content easy with EWW. EWW is also good for browsing local files by hitting W with point on a file in dired.

In dired, I usually launch external programs for photo editing, media playback etc by pressing & with point on a file name. This brings up the completing-read interface in the minibuffer which asks me if I would like to use dired's guess as to which program to use (which I have set to guess xdg-open first) or something else. I press return and then mpv, gimp, darktable or whatever launches with the file.

I had an html file in my downloads folder which I launched with W to read in EWW. I then, by mistake, hit W when on a .mp3 file, and it launched in mpv. Since W launches the file in EWW and EWW was configured to open .mp3 files in mpv, it did that without asking me which program to use. It is faster to hit W than to hit & RET, or in worst case write a program name and RET. So now I launch media files with W in dired in stead of using &. It speeds things up a bit.

(While writing this, I also remembered that I have functions for playing enclosure links and links in elfeed through mpv that I might replace or improve by shuffling the links to EWW or einar-browse-url-mpv. I wrote my configuration for elfeed very early in my Emacs journey, without really understanding any of it, by copying snippets from the Emacs wiki, blogs and Reddit so it is high time to look at it again anyway. I can probably simplify it.)

Here are the relevant parts of my configuration for EWW to get this working:

(defun einar-browse-url-mpv (url &rest _args)
  "Opens URL in mpv."
  (start-process "mpv" nil "mpv" url))

(use-package eww
  :config
  (setopt browse-url-handlers
          '(("\\(youtube\\.com\\|youtu\\.be\\|vimeo\\.com\\|twitch\\.tv\\)" . einar-browse-url-mpv)
            ("\\.mp3$" . einar-browse-url-mpv)
            ("\\.mp4$" . einar-browse-url-mpv)
            ("\\.webp$" . einar-browse-url-mpv)
            ("\\.m4v$" . einar-browse-url-mpv)
            ("\\.mkv$" . einar-browse-url-mpv)
            ("\\.pdf$" . einar-browse-url-pdf)
            ("." . eww-browse-url))))

Fix Emacs python-mode REPL and org code block with python evaluation problems

For a while now, the python shell in Python mode in Emacs has not worked properly on my work laptop. I get some strange glyphs in the top of the python shell buffer when opening it from a file with C-c C-p and when I tried importing a file with C-c C-c, I would get an error saying stringp was nil and every character in what I tried to import was written first once, then together with the next, then the next three and so on. It looked somewhat psychedelic and was more or less unusable.

I also had trouble evaluating python code blocks in org mode which has been annoying when presenting with inter-present-mode for my students or exporting from org files I used for presentations to PDF or docx to upload to our school's learning platform (it's learning). In org, I would get the same error saying stringp was nil when evaluating code blocks that I would get when trying to import files to the REPL in python mode.

I first thought the problem was related to my einar-python-virtualenv function which locally changes the python-shell-interpreter for a file if it is in a project with a virtual environment since I made that quite recently, but the strange thing was that it worked perfectly on GNU Guix on my main machine at home. I then thought maybe it was a Windows 11 problem since I only experienced it at work, so I tried on a Raspberry Pi 4 at work with the latest Raspberry Pi OS and I had the same problem.

I then tried launching Emacs with -q to see if the problem was related to my config or not. When I then launched the python shell from a file with C-c C-p, the REPL itself worked slightly better, but I still got some strange glyphs at the top. I then spent some time trying to figure out where in my config the problem appeared and removed first the einar-python-virtualenv and then my configuration for python-mode, but the problem persisted. I also looked into whether some setting for comint-mode might cause the problem.

After spending one and a half hour trying to troubleshoot this on Monday, I today realised I updated Python to 3.14 on my work Windows 11 laptop a while ago. I checked the python version on the Raspberry Pi and it was 3.13. I checked packages.guix.gnu.org and Guix uses version 3.11. I thought maybe something changed in one of the newer versions. I had a look at news for version 3.14 and did not find anything promising. I then checked out what was new in 3.13 and one of the first things was a new and improved python shell.

Luckily, you can get the old shell that python mode in Emacs works with by setting the environment variable PYTHON_BASIC_REPL to something. When I added this function call to my Emacs config for python mode, the python REPL works in python mode again and it is possible to evaluate org code blocks and export files that will evaluate them on export again:

(setenv "PYTHON_BASIC_REPL" "1")

I write this so others experiencing the same problem can find a solution. In the long term, python-mode, python-ts-mode and org mode needs to work with the new and improved python shell since the old shell will probably be removed at some point in the future, but for now, just setting the environment variable is enough to get both the REPL and org code blocks working again.