Threads for cipher
-
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.
-
-
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 latest version of the code lets you rebind keys at compile time. Check it out. :)
-
-
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.
-
Do you know vi’s “open mode”? E.g. ex-vi implements it.
-
-
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.
-
-
no virtualbox is a handicap
I use qemu on OpenBSD to run Linux, Windows (admittedly it’s Windows XP :~/), sortix and other virtual machines - I don’t know how it compares to virtualbox but it works well.
In my experience (as an OS programmer), VirtualBox is very buggy and unreliable. QEMU/KVM is much better, indeed. (OpenBSD’s native hypervisor will likely eventually be ready for prime time here, if it isn’t already.)
vmm(4) is already great at running OpenBSD virtual images - but I’ve not tested it with other OS yet - it’s on my todo list
Depends a little if you for example use Vagrant and then VirtualBox might be a lot more handy. In my last job I gave up being the only person with lxc images because everyone else was on mac+virtualbox, so I had to relent.
I have the exact opposite experience. I have been using VBox for many years on Linux and MacOS and it is very reliable.
If your guests are Linux or Windows, it’s well-polished and stable. If your guests are anything else (especially if you’re doing active OS dev on the guest!), I imagine you’ll find holes in short order.
Except OpenBSD doesn’t have KVM, but its own VMM. You’re stuck with TCG for QEMU.
As others have suggested, vmd is your friend here.
While not perfect in terms of speed, I managed to completely get rid of linux @work as a main system.
Now I just fire up an ubuntu instance (to be able to install it you need to make the image boot in console mode, nothing too hard) with x2go-server installed. Using x2go-client, I fire up emacs and I’m set.
Other (+) points (for me at least):
vmctl start <vm-name>away!Of course all the above are dependent to one’s needs. :)
Using the aforementioned work flow, I truly do not care if the vm breaks; and if it does, I just copy my backup image and I’m set. :)
[edited for grammar]