Over on lobste.rs, a link to An Updated Version of sam got posted. In the ensuing discussion, vfoley basically asked what sam users saw in it and I wrote a long answer. I've decided to repost that answer here on Wandering Thoughts, with some additional commentary interspersed.

(Indented text is my original comment; outdented text is additional commentary.)

I'm a long-time sam user. So far sam is the best graphical editor I've used, and one of the very few that actively invites me to use the mouse when editing text; it's just so natural. I should note that I'm a long time user of the chording patch (now in the deadpixi version), which make moving text much faster and easier than it would otherwise be. sam doesn't have very much special power for editing text, but it works smoothly. Also, like vi (and unlike Emacs) it has the virtue that it plays well with other Unix tools in that you can do things like select areas (or the entire file) and pipe them through programs like fmt. As vi users know, this is a great way to leverage the power of everything on your system.

I've written about this before when I talked about my sign of a good graphical interface. Outside of chording for cut and paste, sam doesn't do anything particularly special with basic GUI text editing; it uses the standard selection paradigm; you select text by sweeping the mouse, if you type your new text replaces the selected text, and so on. About the only special thing I can remember sam doing here is that if you double-click at one end of a paired set of delimiters, it selects all the text to the other end. Among other things, this is a handy way to find out just where the other end actually is (and if it's where you expected).

I do think that chorded cut and paste is reasonably important for making sam feel fluid. Fast, convenient cut and paste matters and the chords avoid constantly going into the menus, even if they are convenient pop-up ones. But many selection-based GUI editors have keybindings for this to do the same thing.

Also, sam text selections interact with other aspects of sam because plenty of sam commands operate on text selections. The most commonly used one for me is '|fmt', to pipe the selection through a Unix command and replace it with the command's output. This is just like vi does, but you get to see exactly what you're fmt'ing in advance.

(Yeah, at this point Emacs people mention C-u M-|, cf. I wave my hands and say 'it's not the same in Emacs'.)

One subtle thing about sam is its command window and the command lines that you enter there. These give you extra visibility on what you're doing and also let you successively refine large scale modifications, since you can see, reuse, and extend commands. It's routine for me to start by doing just, say, the part that will select the text I intend to modify; when that's selecting the right thing, I'll redo it with the change command. Did something go wrong? Undo, modify the command, re-send it to try again.

sam is not just a GUI text editor; it has an entire ed-style command line language. In practice I wind up doing a reasonable amount with this language instead of the GUI's menus. You type your command lines into a separate window, which is fully editable and thus allows you to see your past commands, copy and paste them to modify and resend them, and so on.

I personally quite like how sam deals with editing multiple files. I find that it makes it very easy to go back and forth between several files without pain, although having several on the screen at once is not as easy as it is in something like Emacs. Part of this may be that I have never really learned how vi does this and find what I do know somewhat awkward. sam has a clear conceptual model where it has all files loaded in at once, some or all files may be modified from their on-disk version, and so on. Emacs does this too, but sam has the nice popup menu of all the files that makes moving around among them easier for me.

I mostly don't use sam for large scale programming in most languages, because Emacs has all sorts of very nice superintelligent autoindent and this and that. But for quick modifications, or for languages where Emacs doesn't do what I like, or for text, sam works great for me.

(sam's multi-file structured editing also makes it the best tool for certain sorts of mass modifications, because you can easily run a single modification over a whole bunch of files all at once. But at least for me this is a relatively uncommon thing that I might do only once or twice a year.)

I go back and forth between sam, vi(m), and Emacs depending on what I'm doing. Emacs is my big-programming editor; sam is my generally preferred editor if I'm in an X environment where I have it set up; vi(m) is my sysadmin editor because it's always there and works in any environment and starts and runs fast.

I've written about my multi-editor use before at more length. I feel strongly that different editors have different strengths, to the point where you can't say that there is a single best editor unless you confine yourself to a narrow area of editing.

(Note that I have my own Github semi-fork of the deadpixi sam, which I have allowed to drift out of date with the upstream master and which is likely to always have some divergences even if (and when) I update it. Possibly a lot of them. But in general, I recommend that interested parties start with the deadpixi version of sam, if only because of the support for modern X font handling.)