On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <steve(a)quintile.net> wrote: Sam has a neat feature that many people who are not familiar with it may be unaware of: remote editing. In some ways, this is a bit of an historical accident, given the way that sam was developed. The editor is actually split into two programs: there is sam, the editor itself, and samterm, which is the graphical user interface to the editor. On research Unix, `samterm` was meant to be downloaded into the memory of, and run directly on, the Blit terminal (or one of its successors), while it communicated with the actual editor running on the VAX the terminal was connected to. The sam paper goes into some detail describing the protocol between the two, and how they synchronize state. Originally, the two were connected over a serial line, but that was an implementation detail, and really, any reliable byte-stream connection will do. The fundamental mechanism this has been preserved into the modern era, and with recent versions of sam, one can still run `sam -r remote.machine.name`; `samterm` will run locally, but behind the scenes, it connects to a remote machine (e.g., via SSH) and communicates with the actual editor. This is something that I wish more editors knew how to do; emacs can kinda sorta do this with TRAMP, and VSCode and Zed can both do something similar, but require very heavy-weight server components on the distant end (and in the case of VSCode, the remote editing component is closed-source, and only runs on a few platforms). Sam is much simpler and far more portable and served as an example for decades, but for whatever reason, the idea is not common, and most editors seem stuck in the "local machine" paradigm. - Dan C.