Sam is an extremely interesting text editor, and this is a really good paper.
I tried to switch to Sam a while back, because I liked the way it did regular expressions, and how it handled "lines" of text. Unfortunately, I found that you had to be a better/more accurate mouse user than I am. You really need to be pixel perfect to use Sam effectively.
You can try vis [0]. It incorporates Rob Pike's structural regular expressions and modal editing from vim. The very best of both worlds. Have been using it for a while and haven't looked back.
If you want an editor that uses Sam's structural regexes with keyboard-focussed vi-style interaction, you might be interested in https://github.com/martanne/vis
I've tried to use Acme as well and the mouse chords were very difficult to use. I guess it needs an old-school three button mouse (gamer mouses with side buttons didn't help).
If you use Acme from plan9port, you can use Ctrl/Alt (on PCs) resp. Command/Option (on Macs) to simulate chording. That's what I use when I'm on a laptop without my external mouse anyway. At some point, you get very very used to it and start attempting to use the mouse chords in other text entry boxes (such as the browser).
My solution to _that_ is to just write text in Acme always and copy/paste it into the destination when I'm done :)
But there aren’t many mice like these. Personally I picked up the N700 and it’s a fine enough mouse but I wouldn’t use it with any other system except some form of Plan 9 with Acme. Not my favorite.
While a three button mouse is certainly the best, there are some mice (like Logitech G305), where the scroll button can be easily triggered by pressuring it from the side, so one finger can operate both left and middle buttons pretty much independently.
You can also just reprogram the left/right wheel buttons. I personally like the g502/g604. Also I prefer their gaming mice to their office mice, because the gaming mice support on board memory storage rather than needing software to remap the buttons.
Sam certainly rendered text as lines, like you'd expect, respecting newlines as line breaks.
But it had a different idea about lines of text when it came to regular expressions. There was a metacharacter that matched newlines as if they were just another character, so that regular expressions could match blocks of text spanning multiple lines. A separate metacharacter matched newlines the way vim does.
This and other consequences of treating newline characters as just another character gave Sam a different feel, where lines weren't as important.
I use sam -d. It's fairly similar to ed if you are familiar with it, the main differences are the expanded command language, better interface with *nix environments and allowing dot to include newlines, thus having commands work across lines.
In windowed sam dot is the currently highlighted text and you have a snarf, cut and paste editor along with a separate window for commands.
It was a surprise to me to really understand that text files don't consist of lines anywhere, they are byte arrays. Interpreting
97 98 99 13 97 98 99
as text with lines
abc
abc
is just one way to view it, but only 'correct' as far as saying agrees with the author's intent, but not objectively 'more correct'.
I now think that being able to interpret the same thing in many ways, and shift between them at will to use the most useful one or leverage a different tool, is a key skill in computing and programming which doesn't get discussed all that often. Vim uses it in letting you treat it as lines, words, sentences, paragraphs, blocks, screens. Regexes let you treat it as character sequences, arbitrary sequences of patterns, repeating patterns. Hex editors go for the byte level. Structure editors let you treat it as INI blocks, key=value pairs, XML trees. IDEs let you treat it as functions, methods, classes, headers.
And the more of them you can see, the more tools you can use - e.g. treating CSVs as lines of text in one context, then comma separated text, then comma separated dates and numbers and text, then entries in a user database, that lets you do different kind of processing on the same data where someone who sees it only as "a CSV" is more restricted.
(I suspect that's a part of general thinking; being able to see the same thing in different overlapping contexts which let you take it apart at different size boundaries; e.g. a dessert on a table, is also a trifle, which is part sponge cake, which is a flour/butter/egg/sugar mix which is a starch/fat/binding/sweetner and that lets you rebuild it either as swapping the trifle out at your dinner party, or swapping the sponge out for biscuits in the trifle, or swapping the butter for margarine in the sponge recipe. Someone stuck in the pattern "children's parties always have trifle" or "this is an Italian theme dinner party so it has to have an Italian dessert" is limited, someone who sees a trifle as something you buy from a shop and can't make one, is limited, someone who sees trifle as "made with sponge" is limited, someone who sees sponge as a single recipe is limited, someone who can swap any part at any level at their convenience is more flexible, less limited; someone who can do that on the fly for any of the foods on the table, would make a really good cook/host/organizer).
See also: inside computers, it's all bytes, that's all there is.
See also: Steve Yegge classic essay "The Emacs Problem" https://sites.google.com/site/steveyegge2/the-emacs-problem "How did I get so far off the original track of text processing? Well, that's the punch line of this shaggy-dog story: it's all text processing! Log files, configuration files, XML data, query strings, mini-languages, programming languages, transformers, web pages, word documents, everything... the vast majority of your programming work involves text processing somehow. What would you rather do? Learn 16 different languages and frameworks in order to do "simple" log-file and configuration-file processing? Or just buckle down, learn Lisp, and have all of these problems go away forever?"
I tried to switch to Sam a while back, because I liked the way it did regular expressions, and how it handled "lines" of text. Unfortunately, I found that you had to be a better/more accurate mouse user than I am. You really need to be pixel perfect to use Sam effectively.