If anyone uses sam (or another editor that would be considered more “primitive” than something like vim or Emacs), I’d love to hear what you have to say about it. Why use that particular tool, what does it give you that other editors don’t or what does it enable that is important to your workflow? Thanks!
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.
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.
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.
Any chance you could make a screencast? Very curious to see how sam is used as a general purpose editor and how it mixes with the rest of the environment.
I would love to see that too; although I don’t use Acme myself, Russ Cox’s video on Acme and its features is something I watch a couple times per year just for fun.
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.
Sam is nice in many ways. Using it for quite some time for editing small files and replying from mutt.
Also used Sam in a work project, using fzf to select files and open them using B. Quite elegant and simple.
What I like:
- ability to organize your workspace. It’s like a floating wm. Like it way more than acme’s “tiling” structure
- command window
- ability to use proportional font for reading long chunks of text
The only thing I found cumbersome, was that there was no way to navigate using keyboard between open files.
Tried to build Sam fork from deadpixi on OpenBSD, but failed miserably. Seems very nice though. :)
The deadpixi version has Ctrl+K for switching between current editing window and the command window, the b command in the command window has fuzzy matching support, and you can use Ctrl+{W,S,D,X} to move up, left, right, down (not very ergonomic if you was me).
Please check out the latest source on GitHub. It should compile correctly on OpenBSD now; look at the comments in config.mk for information on how to compile.
I’m a huge fan of ed (and sam). I have tried numerous times over the last decade to use ed as my main editor but consistently find myself falling back to something more ‘modern’.
There are relatively few things I miss when using ed but there are a couple of pain points that prevent me from using it as my daily driver:
I really want my line editor to have a line editor. rlwrap gets me 90% of the way there but having a built-in version would be nice. One that supports vi-like bindings would be doubly great.
Better regex. Sam’s structural regex is very nice but even something as ‘simple’ as pcre would be very useful
Have the change command populate the line. There are some occasions where I can’t accomplish what I need with the basic regex and have to change a line. Populating the line buffer with the contents of the line would be very helpful to avoid typing out a majority of the line again.
Mini multi-line buffer: This is something I’ve been thinking about a lot. When in insert mode, it would be nice to edit previously entered lines. Anything between an ‘i’ (or ‘a’ or ‘c’) and ‘.’ becomes a editable multiline buffer. Yes, this really goes against the idea of a line editor but it would be so useful I don’t think I’d care.
Very interesting! Can you explain how you navigate a file using ed? I know enough to modify a file or write a small script, but I’m not sure how I’d navigate in a multi-thousand line file.
Firstly, I make heavy use of a terminal multiplexer. I use tmux splits to open multiple files side-by-side and copy mode to view previous output in the scrollback. Sometimes I keep two splits open with the same file, one for browsing and one for editing.
I use the z command with reckless abandon. Without specifying a number of lines, most implementations will use the windows size as n and display n lines. You can also use zn to print the lines numbers but three keystrokes to browse with line numbers is a little much.
If I need to address a line and I’m unsure of the address, I’ll just use a simple search to find what I’m looking for. If there’s only a few lines using the var $foo, I can /\$foo and keep hitting enter until I find the line I want. If I’m really lazy, sometimes I’ll just ,n to print the whole file with line numbers and use tmux’s search.
The real trouble I run into, which forces me back to something like vim (or vis, these days), is large refactors. I find it very difficult to effectively move around blocks of text and adjust their indentation without immediate feedback.
The change command, as mentioned above, can also be a pain. There are times when you may need to change a small part of a line but you either can’t find a regex that works or you can’t get ed’s minimal regex implementation to play nice. I ultimately wind up using the c command to change the line, requiring me to type out the whole line again.
Indentation sometimes gets me in trouble with my colleagues. I use tabs exclusively when working in ed and have to remember to format prior to committing. This is easier in languages which provide official formatters (go and rust) but requires more diligence with other languages.
If anyone uses sam (or another editor that would be considered more “primitive” than something like vim or Emacs), I’d love to hear what you have to say about it. Why use that particular tool, what does it give you that other editors don’t or what does it enable that is important to your workflow? Thanks!
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.
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.
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.
Any chance you could make a screencast? Very curious to see how sam is used as a general purpose editor and how it mixes with the rest of the environment.
I would love to see that too; although I don’t use Acme myself, Russ Cox’s video on Acme and its features is something I watch a couple times per year just for fun.
Thank you so much for taking the time to write this response, very interesting!
C-u M-|begs to differ…note: using vim as main editor.
Sam is nice in many ways. Using it for quite some time for editing small files and replying from mutt.
Also used Sam in a work project, using fzf to select files and open them using
B. Quite elegant and simple.What I like: - ability to organize your workspace. It’s like a floating wm. Like it way more than acme’s “tiling” structure - command window - ability to use proportional font for reading long chunks of text
The only thing I found cumbersome, was that there was no way to navigate using keyboard between open files.
Tried to build Sam fork from deadpixi on OpenBSD, but failed miserably. Seems very nice though. :)
The deadpixi version has
Ctrl+Kfor switching between current editing window and the command window, thebcommand in the command window has fuzzy matching support, and you can useCtrl+{W,S,D,X}to move up, left, right, down (not very ergonomic if you was me).The latest version of the code lets you rebind keys at compile time. Check it out. :)
http://www.github.com/deadpixi/sam
Please check out the latest source on GitHub. It should compile correctly on OpenBSD now; look at the comments in config.mk for information on how to compile.
I’m a huge fan of ed (and sam). I have tried numerous times over the last decade to use ed as my main editor but consistently find myself falling back to something more ‘modern’.
There are relatively few things I miss when using ed but there are a couple of pain points that prevent me from using it as my daily driver:
Do you know vi’s “open mode”? E.g. ex-vi implements it.
Very interesting! Can you explain how you navigate a file using ed? I know enough to modify a file or write a small script, but I’m not sure how I’d navigate in a multi-thousand line file.
Firstly, I make heavy use of a terminal multiplexer. I use tmux splits to open multiple files side-by-side and copy mode to view previous output in the scrollback. Sometimes I keep two splits open with the same file, one for browsing and one for editing.
I use the
zcommand with reckless abandon. Without specifying a number of lines, most implementations will use the windows size as n and display n lines. You can also useznto print the lines numbers but three keystrokes to browse with line numbers is a little much.If I need to address a line and I’m unsure of the address, I’ll just use a simple search to find what I’m looking for. If there’s only a few lines using the var $foo, I can
/\$fooand keep hitting enter until I find the line I want. If I’m really lazy, sometimes I’ll just,nto print the whole file with line numbers and use tmux’s search.The real trouble I run into, which forces me back to something like vim (or vis, these days), is large refactors. I find it very difficult to effectively move around blocks of text and adjust their indentation without immediate feedback.
The
change command, as mentioned above, can also be a pain. There are times when you may need to change a small part of a line but you either can’t find a regex that works or you can’t get ed’s minimal regex implementation to play nice. I ultimately wind up using theccommand to change the line, requiring me to type out the whole line again.Indentation sometimes gets me in trouble with my colleagues. I use tabs exclusively when working in ed and have to remember to format prior to committing. This is easier in languages which provide official formatters (go and rust) but requires more diligence with other languages.