On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <steve(a)quintile.net> wrote: 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.

Rob Pike wrote in <CAKzdPgyJkbr5H-+t9LEy-RFX8dD7d7Y4RsNhBrRj6yW1rqiObw(a)mail.gmail.com>: |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. A bit off-topic for minimized editor bandwidth, but fine with "End of an Era". The "Timing Analysis of Keystrokes and Timing Attacks on SSH" [1] attack on OpenSSH (that lead to ObscureKeystrokeTiming ssh_config(5) option, aka "obscure inter-keystroke timings from passive observers of network traffic") was one of my deepest "boah!"s/take a deep breath of the last years. Compared to when i discovered Linux, but then FreeBSD with all the documentation and papers, and all that, and reading code, of course, over 26 years ago, it lost its, well, innocence. By then, at my programming level at least, you disabled Nagle's algorithm, and at worse used SSL, to mischieviously rub your hands and be fine with it. [1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf |-rob | | |On Thu, Jul 24, 2025 at 1:27 AM Dan Cross <crossd(a)gmail.com> wrote: | |> On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <steve(a)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. |> |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 <[1]crossd(a)gmail.com[/1]> wrote: | | [1] mailto:crossd@gmail.com | ||On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <[2]steve(a)quintile.net[/2]> \ ||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 ||[3]remote.machine.name[/3]`; `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. | | [2] mailto:steve@quintile.net | [3] http://remote.machine.name | || - Dan C. --End of <CAKzdPgyJkbr5H-+t9LEy-RFX8dD7d7Y4RsNhBrRj6yW1rqiObw(a)mail.gmail\ .com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |During summer's humble, here's David Leonard's grumble | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure | |Farewell, dear collar bear