notes from /dev/null - computer

An accidental lock-in feature of the Apple ecosystem

2024-06-12T01:25:00-07:00

It’s WWDC week, when Apple shines their spotlight on its developer ecosystem every June. Given the moment, I’d like take this opportunity to give all the flowers to the unsung developers who have built and maintained a feature in Apple products that I hold quite dear: the Emacs keybindings in Apple UI frameworks.

If you don’t know, when using a macOS native app like Notes, OmniGraffle, or Safari, you can use the following keybindings in any text field:

C-a - move cursor to beginning of line
C-e - move cursor to end of line
C-f - move cursor forward one character
C-b - move cursor backward one character
C-k - kill text to end of line
C-y - yank killed text (mostly, more on this later)

It can not be overstated how extraordinarily convenient this feature is to Emacs users. Even more astonishing is how this set of bindings has continued to be maintained (since 2001!) across the different OS variants Apple ships (macOS, iOS, iPadOS, tvOS).

Backstory

My anecdotal understanding of this feature’s history is that it started with the NextStep OS back in 1988. The developers of NextStep used Emacs and so whenever they typed in the text widgets of the NextStep UI, they naturally wanted to use Emacs bindings. It was unlikely that this was ever an exec-level requirement. But the developers wanted it, so they made it happen.

Fast forward in time, NeXT effectively acquires Apple and in doing so repackages the NextStep frameworks to ship Mac OS X (now called macOS). This decision fatefully keeps NextStep’s text system and its conventions intact in the UI framework called AppKit as part of family of frameworks called Cocoa. Fast-forward to 2007, the iPhone becomes a thing. Apple makes another fateful decision to build iPhone OS (now called iOS) off of Cocoa but create a new touch-based UI framework called UIKit. UIKit’s text system is heavily influenced by Cocoa where it too carries over the Emacs keybindings. Variants of iOS in the form of iPadOS and tvOS come to be, further propagating these keybindings. In 2019, a declarative UI framework called SwiftUI is created where its text system too adopts the Emacs keybindings.

Configuring Keybindings in macOS

Wonderfully enough, you can still configure the keybindings in AppKit-based apps on macOS using the NextStep style configuration as shown in the Text System Defaults and Key Bindings document. There it provides guidance on adding more Emacs-style keybindings.

Of note is that macOS has always supported an alternate clipboard to emulate the Emacs kill-ring. This works independent of the system clipboard, and requires a bit of configuration to get working. There are two steps to this:

Redefine the keybinding C-y to yankAndSelect:

In the file $HOME/Library/KeyBindings/DefaultKeyBinding.dict (for details see the link above), add the following line in the body between the braces.

"^y" = "yankAndSelect:";

Use the command line utility defaults to set the variable NSTextKillRingSize.

This variable controls the size of the kill ring. Here we will set it to 5.

$ defaults write NSGlobalDomain NSTextKillRingSize 5

You can confirm the value in NSTextKillRingSize as follows.

$ defaults read -g NSTextKillRingSize

Refer to man defaults for more information on it.

At this point, you will need to log out and back in for the new keybindings to take effect.

Caveats

You can’t have everything though as not all apps are built with AppKit. Focusing on only the default Emacs bindings, here’s a survey of the different levels of support for them from the different UI frameworks.

Binding	AppKit/SwiftUI (macOS)	UIKit/SwiftUI (iOS, iPadOS)	Mac Catalyst
`C-a`	Y	Y	Y
`C-e`	Y	Y	Y
`C-f`	Y	Y	Y
`C-b`	Y	Y	Y
`C-k`	Y	Y	Y
`C-y`	Y	N	N

Unsurprisingly, UIKit chose to not support a kill ring, so effectively C-k is a delete function and yanking is not supported. The column for Mac Catalyst is a category of apps built to work for both iPadOS and macOS based largely on UIKit. Such apps include Messages and Stocks.

Closing Thoughts

I’ll never take for granted the repeated decision over the years by the Apple text system developers to keep supporting the Emacs keybindings. While perhaps not intended, this feature quite seriously is an ecosystem lock-in factor for me. It is a gift and to some extent, a secret handshake, that I’ll always be grateful for. To whoever was, is, or will be involved with keeping this feature alive, thank you.

Introducing regfmt

2022-10-25T11:31:00-07:00

Sometimes a project you've had in the mental back burner for decades calls to you again, but this time you pay attention. So it is with regfmt, a command line utility that I spent this past month working on.

Backstory

While I was in grad school back in the early 1990's the department had prescribed using the AT&T troff tools for writing papers. Among those tools was one called dformat, which enabled you to easily draw out control register-style data formats using a domain specific language (DSL).

dformat was a great tool for its time but over the years got consigned to bit rot and ultimately forgotten by many. Among the reasons for it being forgotten was that it only supported the troff specific pic drawing language and used a make-shift DSL for its input.

Today

The world moved on and settled on other tools for writing and drawing. That said, the fundamentals of computer design haven't changed and control registers are still a thing, so the need to draw them out is still a thing, and drawing them by hand is still painful.

In the intervening time from the early '90s to 2022, I've run into times when I wished I had something like dformat but modern to use for writing technical documentation. What's modern you say? How about having:

a common vector graphics file format output such as SVG which can then be easily converted to a raster format (png, jpg, etc.).
an input specification that is based on a common data serialization language.

In the early summer of 2022, I got to thinking about dformat and how it could be re-imagined for today and realized wow, all the pieces I needed were there:

Use SVG for the output format
Use YAML for the input format
Use CSS to style the output
Implement in Python which has support for all of the above.

In October 2022, I found the cycles to go to work on this.

Announcing regfmt

regfmt is a Python command line utility to generate SVG diagrams for control register-style data formats. It is inspired by the dformat command from the troff family of tools, however re-imagined using contemporary (circa 2022) file formats.

Python installation: PyPI: https://pypi.org/project/regfmt/

Source Repository: GitHub: https://github.com/kickingvegas/regfmt

Example output of regfmt

Features

SVG output
Modern configuration input file formats
- YAML for register configuration
- CSS for styling SVG output

Try it out!

If you need a tool like this, please take the time to try it out. Any feedback would be appreciated!

Requirements

Python: ≧ 3.9

Installation

regfmt supports installation via PyPI. Is is recommend that you do this in a Python virtual environment.

$ python3 -m venv .venv
$ source .venv/bin/activate
(.venv) pip install regfmt

NeXT is the reason why you have your iPhone.

2011-09-01T02:23:00-07:00

One of the things that I always marvel at in computing is how strong an idea can persist and if the idea is good enough, will find its moment in the Sun.

Back in late 80's, Steve Jobs with a superbly talented team of hardware and software engineers set out to make a computer that would offer a “new kind of computing and software development environment.” That computer would be called NeXT.

NeXT made a point to market themselves to the higher education market and in late-1988 they started making rounds to colleges to pitch their yet-to-ship computer. At that time, I was a graduate student at the University of Virginia and as such got to attend an on-campus presentation of the first NeXT computer. It was gorgeous in all its greyscale beauty. It was also crazy expensive, with the base model listing at $6,500 with no hard drive. While the technology and pricing were competitive with the workstations of its time, NeXT was really priced in the realm of institutional purchasing and not for individuals.

At the presentation there was of course product information, which I took, studied, and then shelved away. The years passed, and through circumstances well documented elsewhere, the operating system built for the NeXT computer would become the basis for OS X and then iOS: the OS driving Macs, iPhones, and iPads today. But it's not only a software story. NeXT and all the other workstation manufacturers of its time (Sun, SGI, Apollo, etc.,…) were really pushing what could be achieved with microprocessor-based computers, shoe-horning in architectural concepts from mainframe and mini-computers to improve performance wherever possible within the economics of the early 1990's.

With Moore's law, scaling has yielded system-on-chip (SoC) devices inheriting from workstation hardware architectures and system software, enabling the nascent ubiquitous computing world we see today.

Back to that product information from 1988, I still have them on my bookshelf. With the recent announcement of Steve Jobs' resignation, it seems as good a time as any to share them with you. They are a fun read: it's marvelous to see how coherent the vision of that talented team building NeXT has held out over the years.