[TUHS] upwards from ed (was: End of an era: the last ATC)

[Rob Pike]

Sam -r was a boon when living in Sydney but working in California. Compared
to the people around me using SSH to log in remotely and then using vi or
EMACS, the UI latency difference was more than noticeable. Round trip for
each keystroke was the better part of a second, except for me. Local echo
for the win.

-rob


On Thu, Jul 24, 2025 at 1:27 AM Dan Cross <crossd at gmail.com> wrote:

> On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <steve at quintile.net> wrote:
> > sam was my only editor from 92 when i discovered it until last year.
> > [snip]
> > i would love to go back to sam but i fear adding treesitter and the rest
> needed to support this feature would kill one of us for sure.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20250724/01ae6785/attachment.htm>