Category: Programming

emacs upgrade from its git repo

whbeebe

There is a full Emacs Git repository on the Emacs Savannah site. I had cloned a local copy to work with, but when I read the README and then tried to run configure, there was no configure script to run. I didn’t know why at the time so I deleted the local clone copy and instead downloaded a released source tarball and built from that. Before deleteing the clone copy I found out that that version was 30.0.50.

After building version 28.2 and then building a minimal init.el, I cloned the Git repo again with the intent to do a bit more reading. Sure enough, buried in the top level README text file was a single reference to the script autogen.sh. I ran that script and it in turn produced the necessary configure script.

The version of configure for this version of Emacs wanted makeinfo, which is a part of texinfo. Sure enough Linux Mint 21 needed to have texinfo installed, which in turn fullfilled the makeinfo build requirement and allowed configure to complete. Once completed I installed that emacs locally to my home directory and started to use it. No problems encountered so far, and my very modest init.el works identically in this latest version as it did in Emacs 28.2.

My biggest annoyance so far is cosmetic, and that’s with attempting to duplicate Vim’s PowerLine feature. I found several Emacs Lisp packages that attempt to replicate the look, but they don’t seem to want to work with my Emacs theme, doom-material-dark. So I’ve turned it off/removed it from my init.el file. I’ve started to re-learn Emacs Lisp again, with an eye towards either fixing one of the existing packages, or else trying to write something from scratch.

Otherwise I’m happy with how it works. There’s a slight irony in me selecting Emacs because of its small resource footprint compared to VSCode. I remember distinctly “back in the day” when Emacs was the heavy-duty application that sysadmins frowned upon, especially those with multi-user resource-constrained boxen running Unix or VMS. I knew  a guy by the name of Bob Talley (one of the three Bobs) who, in the mid-to-late 1980s ran a microVAX at his home, upon which he ran Emacs. This was a machine with two whole megabytes of RAM and a ridiculously small DEC hard drive. It was his personal system upon which he hosted Emacs, and according to him he lived inside of Emacs, although I don’t know what that means exactly. Bob took great pride in multi-month uptimes as well as having a local terminal constantly logged in. He could do that because he was the only user on the system. Leap ahead 35 years and I’m running the latest Emacs release on a personal computer running Linux Mint that cost a fraction of what that microVAX cost, with 16 GB of RAM, a 1 TB SSD, a 64-bit processor with four hyper-threading cores, the same shape and size of Apple’s Mac Mini, upon which Emacs is now considered a light-weight tool. So much computational power that was unaffordable back in the mid-1980s, but which is considered more than sufficient today. At least by me.

going back to emacs, again, again

whbeebe
emacs version 28.2

This isn’t the first time I’ve pulled up Emacs and dusted it off, to dive back in again as a daily driver for code writing. The last time I did this was back around the middle of 2020 when I was trying to find a relatively powerful  code editor for Raspbian on an Raspberry Pi. This time I’m writing lots of Python and C++ for embedded work as well as general application programming. I’m even working to add syntax highlighting support for Go Lang and Rust. Right now the syntax highlighting for C++ is just dandy.

Why have I flopped back to Emacs Yet Again? Because I got tired of Visual Studio Code. I have a small, modest development box built around the Minus Forum UM250 with an AMD Ryzen 2500U. It’s a modest machine with a tiny hardware footprint, more than adequate for my uses as long as I’m careful what I run on the system. Most of the time when I’m working the system fan is totally quiet. But recently I started the hear the fan running slowly in the background. I run btop in a terminal, so I started to look at how the system was running, and sure enough, something was constantly pushing the CPU enough that the fan was running slowly. I did a little bit of investigative work and I discovered that if I had the latest version of Visual Studio Code up on the desktop with a project open, the fan would run as if there was a bit of a load on it. As soon as I closed VSCode, the fan stopped turning and btop showed that the CPU usage dropped down to a minimal level. Start up VSCode again, and the load ticked up as did the fan running. VSCode didn’t use to do that.

While there are some plugins I now use for embedded work in VSCode, there’s an awful lot I can do with Emacs. I downloaded the latest source tarball from the Savannah Emacs site, unpacked it, configured it, built it, and installed it. Afterwards I tinkered together an Emacs initialization file (see the listing that follows) to give me a minimal look and functionality that I found satisfying and then away I went. I find it interesting I still have the Emacs keyboard muscle memory, in spite of drifting away from it a number of times over the years. But it’s been a good 30 years since I was first introduced to Emacs, so that counts for something, I suppose.

(setq inhibit-startup-message t)(setq inhibit-startup-screen t)(setq global-display-line-numbers-mode t)(setq gc-cons-threshold 50000000)(setq large-file-warning-threshold 100000000)(prefer-coding-system 'utf-8)(set-default-coding-systems 'utf-8)(set-terminal-coding-system 'utf-8)(set-keyboard-coding-system 'utf-8)(require 'package)(setq package-enable-at-startup nil)(add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/"))(add-to-list 'package-archives '("gnu" . "http://elpa.gnu.org/packages/"))(package-initialize)(unless (package-installed-p 'use-package)  (package-refresh-contents)  (package-install 'use-package))(eval-when-compile  (require 'use-package))(setq frame-title-format  '((:eval (if (buffer-file-name)   (abbreviate-file-name (buffer-file-name))   "%b"))))(setq scroll-margin 0  scroll-conservatively 100000  scroll-preserve-screen-position 1)(set-frame-font "Hack 13" nil t)(use-package doom-themes  :ensure t  :config  (load-theme 'doom-material-dark t)  (doom-themes-visual-bell-config))(setq-default tab-width 4  indent-tabs-mode nil)(global-set-key (kbd "C-x k") 'kill-this-buffer)(add-hook 'before-save-hook 'whitespace-cleanup)(use-package diminish  :ensure t)(add-hook 'prog-mode-hook #'display-fill-column-indicator-mode)(custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(cua-mode t) '(custom-safe-themes   '("84d2f9eeb3f82d619ca4bfffe5f157282f4779732f48a5ac1484d94d5ff5b279" default)) '(font-use-system-font t) '(global-display-line-numbers-mode t) '(package-selected-packages '(use-package)) '(save-place-mode t))(custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. )

My Emacs initialization file is located in ~/.emacs.d/init.el. I’m sure there are other features that I could add, or better plugins for the theme, but right now Emacs is fast and useful, and has a much lesser resource footprint that VSCode. I’m glad I’m back to using it again.