going old-school with emacs on raspbian

Here’s another one for the Raspbian Buster notebook. I spent a bit of time trying to install Microsoft’s Visual Studio Code by following these directions at https://pimylifeup.com/raspberry-pi-visual-studio-code/. After setting up all the dependencies, downloading the tarfile and pulling it apart, then attempting to run the script that would install and build everything else, the VS Code installation failed because the JavaScript engine ran out of heap space. Fine. I’ve used VS Code everywhere else, including Linux systems with only 4GB of memory, but I’ve never had a heap-space issue before now. To be truthful I like working with VS Code and all its various plugins. I would have tried to debug the blocker, but I decided to cut my losses then and there.

I got to the point of trying to install VS Code because I found myself thrashing about looking for a comfortable code editor and almost IDE. I say almost IDE because, after nearly two decades immersed in IDE development environments, I’d grown tired of it. VS Code was a nice step back. But it wasn’t going to happen on the Raspberry Pi 4 with Raspbian Buster. That’s when I turned back to VIM (VI Improved) and rather quickly got it into pretty good shape for my needs. But something still nagged at the back of my mind, and as good as Vim has become, it just wasn’t quite right. I then figure, what the hell. I’ll install and try Emacs again.

I was introduced to Emacs back in the early 1990s by an Emacs goddess. That is no exaggeration. She could code rings around all the other guys, and part of her prowess can be attributed to her mastery of Emacs. She showed me how much better Emacs was over vi and then set me up with some directions and  a beginning .emacs file. I learned how to edit with emacs and how to configure it to fit my tastes. It soon became my default editor, and I carried around my .emacs file from project to project. But a funny thing happened on the way into the 21st century. I got swept up into the bigger-is-better development tool environment and eventually forgot about Emacs.

Until today. It’s been so long since I’ve used it that I’ve had to open up a basic web-based user manual and started to build an .emacs from scratch. Fortunately for me Emacs has evolved considerably. The version I’m using now is a desktop client, and it’s menu support has allowed me to quickly get back up to speed again with regards to setting up a decent visual environment. All the very old muscle memory is coming back, and I think I understand part of my uncomfortable feeling with Vim; a lot of the key sequences are too close together. Being back in Emacs, everything just falls naturally back into place.

Emacs is not better than Vim, and Vim isn’t better than Emacs. But Emacs is best for me.

building much, much faster – python 3.8 beta 4 on the rpi4b/4GB

Nearly a year ago I wrote about building Python 3.7.0 on a Raspberry Pi 3B+ with Raspbian 9.4 (/2018/09/16/python-3-7-on-raspberry-pi-3b-and-raspbian-9-4/). One key highlight was how much time it took to build including any testing, which was two to three hours. I build Python 3.8.0 beta 4 on the Raspberry Pi 4B, on the SSD, and it took around 30 minutes (I say around, because I wasn’t paying much attention and certainly wasn’t timing it). When it finished I installed it in a folder on the SSD as well, and then started some minor testing on my own.

If you’re going to do something like this, then make sure that after an install you remove all soft links bin directory. The bin directory should look something like this:


All those links will end in a ‘3’, such as ‘python3’, and if you have the path to where you installed the Python 3.8 beta binaries in your overall $PATH, then you’ll pick it up instead of the default. So remove those links for the time being and instead use python3.8 when you want to test.

One more minor detail, which I started doing when building Qt5, and that’s create a build folder away from the source folder. Configure and build out of the build folder, so that if you need to rebuild with different configuration or different features, it’s simple to just create a second separate build folder and run everything again. For example:

Everything is in the build folder instead of commingled in with all the source. I wrote in last year’s post to build inside the source code folder after you unpacked it, and that was poor advice on my part.

A Tipping Point

The Raspberry Pi 4, in spite of its few rough edges (excess heat generation, non-standard USB C power connector) is still an excellent development platform, especially at US $55 for the 4GB version. With the drop in price of solid state storage prices you can build a very good Raspbian development system and do all your work natively instead of cross-compiling on another system (Linux or macOS or Windows 10). It keeps costs down considerably, especially if you’re on a budget. Even if you’re not, it’s still an excellent bargain all around. If you want to purchase a Raspberry Pi, then the 4B with 4GB is the one to get. With the extensive ecosystem and user community that’s built up around the Raspberry Pi, there’s no longer any excuse to hold back.