Recreating the Canon Cat document interface | Hacker News Reader

Recreating the Canon Cat document interface

lab.alexanderobenauer.com

118 pointstonyg16 comments

I just learned about the Canon Cat a couple of days ago! I wrote up a blog post with some resources and tidbits: https://anderegg.ca/2025/10/13/the-canon-cat

I had a lot of fun with this emulator on Archive.org, and included some quick notes about using it with macOS: https://archive.org/details/canoncat

All of vintage computer emulators on the Internet Archive owe a tip of the hat to the Canon Cat emulation, because that was the computer that started me on automating the original cross-compilation infrastructure.

Archived Twitter thread: https://threadreaderapp.com/thread/1150798839294627842.html

Gist with links to the actual scripts behind the scenes: https://gist.github.com/vitorio/4e5d8de0db5c56b6816b95817c20...

Thanks for your work!

> The hard part is that the Canon Cat had bespoke hardware with dedicated keys for its actions

I actually designed a PCB / custom keyboard (well, it's just a copy of the Canon Cat layout) with the Leap, Use Front, etc keys (using an ARM dev board called Black Pill, which is probably overkill, to scan the rows/columns for key up/down events) for this reason. Right now I have it sending key codes over a serial connection to another microcontroller with a display module so you can now type on it, but I really need to get started on the actual Canon Cat style software. I'm not really planning to make it USB compatible or use any existing OS though.

> Maybe predictably, early on I found myself wanting more than one text stream. I fought that inclination to discover what’s in store down the pure Canon Cat path.

I think the Cat would let you do that if you used multiple disks? I haven't used a Canon Cat, but only read the documentation. It used a single DISK button for loading and saving, based on context. The following quote is copied from the manual for reference. I think the "beep" option is for if you've made an edit in memory but don't have the correct disk in for saving that same text stream.

[quote]

The Cat has two storage places for your text: memory and disk. Memory is the area inside the Cat where the text is stored while you are working on it. The on-screen text is a portion of the text stored in memory. The memory is kept alive by the electric current coming from the wall. If the power were cut, the text in the memory would be lost, so you need to record the text more or less permanently on a disk with the help of the disk drive.

One command, [DISK], handles all operations involving disk and memory. When you use [DISK], the Cat does one of three things:

-Plays back the disk in the drive. This means copying the information from the disk into the memory, and putting a portion of it up on the screen where you can see it and work on it.

-Records the text in memory. This means transferring the information in memory to the disk for safe storage.

-Beeps. This means the Cat makes a warning sound and does nothing, because recording or playing back might lose information.

A DISK sign appears on the ruler while the Cat is recording or playing back.

[unquote]

This does mention Archy, but not in any depth. It doesn't mention The Humane Interface (https://en.wikipedia.org/wiki/The_Humane_Interface), THE, or RCHI. I wonder what the reason is for these omissions? You'd think they'd be central to any discussion of recreating the Canon Cat document interface!

Bootstrapping Computing looks interesting.

I wasn't familiar with (or had forgotten) those acronyms nor Archy. Looks like RCHI stands for Raskin Center for Humane Interfaces. THE stands for The Humane Environment which is what Archy used to be called. https://en.wikipedia.org/wiki/Archy_(software)

Sounds like it had the problem of not using a custom keyboard.

Yup.

Don't the Canon Cat "Leap" keys behave like the ordinary incremental search in Emacs? That is, C-s and C-r for forward and reverse search. Can't you recreate the Canon Cat experience in Emacs by editing in a single big buffer, using C-s and C-r to navigate by searching?

Some of us already do something like this by keeping a big ever-growing notes buffer with the date at the beginning of each day's work.

I think Jef Raskin credited Stallman and Emacs with inventing incremental search, saying that all text search was "either incremental or excremental". In The Humane Interface, a page or so earlier, he introduces it by saying:

> The less common strategy is the incremental search, a popular example of which is found in EMACS, an editor used with the UNIX operating system (Stallman 1993). In most implementations of incremental searches, as with the delimited search, the user first summons a dialog box that contains a field in which the user can enter the pattern. When he types the first character of the pattern, however, the system uses this character alone as a complete pattern and immediately begins to search for the first instance of that character in the chosen search direction. If an instance of that first character is found before the next character of the pattern is typed, the instance is selected ...

HandyFind, which has an ambiguous relationship with Raskin, says:

> Being able to find words as you type has been a popular feature in editors used by software programmers for a long time. The feature usually goes by the name "Incremental Search". The initial idea and implementation was done circa 1974 by researchers at MIT and later included in the popular word processor named "EMACS" (Richard Stallman, 1979). Recently, this feature has become more widespread and is sometimes referred to as Find As You Type, Search As You Type, Type Ahead, Inline Search, Interactive Search, Look-Ahead Search or Word-Wheeling. The claim that incremental search and LEAPing should be a fundamental part of making software easier to use was argued by Jef Raskin in his excellent book The Humane Interface, along with many other great ideas!

(http://www.handykeys.com/about.htm)

One critical difference is that Emacs incremental search is modal: sometimes (in incremental search minor mode) typing "x" adds it to your search string, and sometimes (in, say, fundamental-mode) typing "x" adds it to your document. The advance (as he saw it) of LEAP was that it's quasimodal, like Ctrl or Alt, and therefore much less prone to user error. It's also, I suspect, faster to use (though I've never had a Cat to try on); you'd think that going to the end of the sentence by typing LEAP-. would be about as fast as typing M-e, while using Emacs incremental search in the same way requires typing C-s . RET. That is:

    press LEAP
    press .
    release LEAP || release .

vs.

    press Ctrl
    press S
    release Ctrl || release S
    press .
    release . || press RET
    release RET

which is just a significantly longer sequence of actions that must be carried out perfectly. (Actually you can release S and . in the sequence as late as you want, assuming you don't have key jamming problems, but you still need six steps instead of three.) I haven't modeled this with GOMS or anything but it seems like it would take longer.

As for "one big text file", yes, that was the major finding of Danny O'Brien's ethnographic work on "Life Hacks".

Apologies for bringing vi into it but wouldn't the vi / or ? search be even closer? put your search in then hit n to repeat.

I think the real genius of the interface is reducing it down to a set of dedicated keys that always work. It is hard to explain how good an interface feels if you can get it down to one action. The closest common analog I can think of is the X11 single click paste. When you spell it out "well, copy/paste changes from [select, ctl+c, click, ctl+v] to [select, click]" it does not sound like much. But It flows so much better and I have to admit I get all sorts of grumpy when going back to a windows machine and I do not have my single click paste. On reflection drag/drop might be close to single click paste. But I never do it. Does anyone use drag/drop for common editing?

No, vi's / or ? isn't incremental. This was one of the significant differences between vi and Emacs in the 01980s and 90s, when "vi vs. Emacs" was a thing. Vim added incremental search as one of its enhancements over vi as an option sometime in the 90s and made it the default much more recently, maybe in the last 15 years.

I believe I did have a co-worker who used drag-and-drop for common editing in NEdit in 02005. On that team we used pair programming, so I had the opportunity to observe my co-workers' editor habits in detail. In more recent work I have not had that opportunity.

nvi does. Also,

   set incsearch

at .exrc

The other sort-of brushes off the light spreadsheet and database features of the Canon Cat. I think that that was an important part of what Raskin was going for; there is only one type of document and you can accomplish any number of things within them.

Yeah, this was a big part of the system. It was a full office suite in a document.

>keys

Under Emacs or X11 you can nearly map every key/keybinding to anything.

Also, on The Humane Interface, and the "Undo for everything"... Emacs has desktop-mode and for sure it could be set to save/restore nearly everything. https://en.wikipedia.org/wiki/The_Humane_Interface

Love this. Looking forward to having a play around with it.

Reply on news.ycombinator.com