Wandering Thoughts archives

Why I like the sam editor

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

The harm that comes from ZFS not being GPL-compatible

One of the big issues with ZFS for Linux people is that it is licensed under the CDDL, not the GPL (v2 or otherwise). In the past, I may have sort of said that this wasn't a too big deal because, for instance, there would have been major practical obstacles to getting ZFS code into the kernel anyways. I take that back unreservedly; I was wrong. I have come to see ZFS's license as a real problem for the simple reason that ZFS's license keeps it from being bundled with most Linux distributions.

Now, what makes this happen (or not happen) is not the legal technicalities. Some people feel the CDDL is not actually incompatible with the kernel GPLv2 license, and Canonical certainly thinks there is a legal way around things (since they're doing it in Ubuntu 16.04). And as a practical matter, a Linux distribution would probably not get sued. But software licenses are social things too, and the social side is quite clear: quite a lot of people feel that the kernel's license and ZFS's license clash in a way that means you cannot and should not combine them. A move to do so anyways that's justified on legal technicalities is going to make a bunch of people angry (and has, with Ubuntu 16.04).

I have come to feel that this lack of bundled ZFS on Linux matters quite a bit because ZFS on Linux remains your only real choice for an advanced, checksum-based filesystem. Btrfs remains not a viable alternative and when people are finding serious problems in btrfs's RAID 5/6 code, it's going to stay that way for a while. If ZFS was licensed in a way that was (socially) compatible with the kernel, I'm pretty convinced that a bunch of distributions would have already shipped ZFS on Linux in some form and a bunch of people would be using it and thus would have better-protected data.

(I don't think distributions would have integrated ZFS on Linux into their kernel source. But they could have shipped it as a separate package with precompiled kernel modules and so on, and the odds are higher that they would have supported it in the installer as an option for user filesystems.)

(I wrote about parts of this in an earlier entry, but back then I saw it from a somewhat different angle and I didn't consider the ZFS on Linux effort to be as well-proven and solid as I do now.)