Recreating the Canon Cat Document Interface

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.

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...

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?

   set incsearch

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".

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