hckrnws

The best part of sam are the structural regular expressions. I keep a copy installed just for them. Now admittedly I never use it enough to get good at it so every time it is usually 10 minutes swearing at the manual.

The standard unix regular expression implementations (grep, sed, ed, vi) are very tied to "lines" of text, and most of the time this is exactly what you want. but sometimes it gets in the way. And when you start to have trouble with your regex because it is conflicting with line returns, then it is the sam editor and it's structural regex engines time to shine. They would probably be great elsewhere, but nobody else uses them.

Is there a document that describes these? I've seen them mentioned before as one of the superpowers of Sam, but I've never seen a clear explanation of them for someone who isn't already a Sam user. I have no real intention of ever using or trying Sam as my daily text editor for a handful of reasons, but I am interested in new paradigms and tools for working with code.

http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

look for the section on structural expressions.

I am not really an expert but my understanding is that they are called that because you can use them to define the structure of a match. in most regular expression engines the structure is defined as a line of text or the whole document and the expression only matches the contents. This is why they do so well with multi line records you just need to define a structure expression that matches your, well.. structure.

I never did learn sam all that well, I mainly used it as a non interactive sed replacement. however I just learned that apparently the vis project uses structural expressions. I might try it. Mainly because at least then my fingers sort of know what to do.

Yes, this one: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

> when you start to have trouble with your regex because it is conflicting with line returns

That definitely happens, but 9 times out of 10, you can add /m to the end of the regex, and now ^ and $ match individual lines, while \A and \Z match the entire string.

Also a fan of structural regular expressions in the exact same shoes that every time when I try to use it it's an unpleasant experience. Maybe I'm just not good enough at it.

That being said, I've been recently employing comby (https://comby.dev/) in my workflow, which solves similar problem, but understands certain languages to simplify the usage.

Have you tried vis? https://github.com/martanne/vis

I've been using sam for close to 4 years now for writing C, best editor I've ever used. In combination with the plumber I don't feel like I have much more to ask for. Rob tended to quite like mouse navigation and I tend to agree with him, I never bothered making space in my head for very specific navigational commands in say vim, versus just moving the mouse to where I want the cursor to go.

Why Sam over acme?

Acme restricts the use of the edit language to 'Edit' commands given in the tag bar. For someone who uses those commands quite often, I don't find this ergonomic in the slightest. I also have issues with the way windows are managed, but this is perhaps only personal taste.

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.

[0] https://github.com/martanne/vis

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 :)

That might actually work for me. Will give it a try.

9front’s got a couple of recommendations: http://fqa.9front.org/fqa3.html#3.2.0.1

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.

I've got a Logitech G403. It's got a little DPI switch button behind the wheel, which you can reprogram to act as the middle mouse button: https://www.logitechg.com/en-gb/products/gaming-mice/g403-he...

Your preferred settings can be saved to the mouse's onboard memory, so you only have to install the programming crapware on one system.

There are some forks (or reimplementations) of acme that have more keybindings, allowing you to avoid mouse chording. Here are a couple that I like:

https://github.com/karahobny/acme2k

https://github.com/aarzilli/yacco

HTH

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.

If the G305 is anything like other Logitech mice, pushing sideways on the scroll wheel will scroll horizontally.

Maybe the ones of the office variety? This particular mouse has only one switch under the wheel, which can be pushed downwards or to the right.

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.

In my brief acme foray, I somehow bound a keyboard press to middle click? Dont quite remember the details

I tried Acme a while ago but gave up. I remember using a MacOS app that simulated middle click.

Not having used sam, but having used Linux since the 90s, why is "lines" quoted? Do text files not consist of lines, in sam?

My memory is slightly hazy, but...

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

    abc
    abc

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

As usual, reference to Oberon OS, where Sam gets its influence of how the UI and mouse gestures work.

I'd really like to see a video of someone using Sam. I sort of understand the concepts individually, but I don’t see how they come together in a fluid way for actual programming. Acme is easy to grasp, Sam has eluded me. But Sam users seem to _really_ love it and I want to understand why.