Having a long interest in editors for more than 40 years, I've made serious use of vi, emacs, and jove. I've also played with about a dozen others, including sam. I now use IntelliJ. It is a very poor editor but has a number of modern features that I can't work without.

After all this experience, there is one editor that stands out as the most interesting to me, and that is ACME!

I like the i3/sway desktop because it maximizes screen utilization and doesn't hide anything. It is, in my opinion, the most productive use of screen real estate. ACME has the same philosophy.

Unfortunately, ACME has a very small following, poor availability, poor support, and poor portability. There are also many great features that could be added. I'd love to see it take off. I'd do it myself if I had the time.

Just a random opinion.


Blake McBride
blakemcbride.us



On Fri, Jul 25, 2025 at 3:57 PM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
Rob Pike wrote in
 <CAKzdPgyJkbr5H-+t9LEy-RFX8dD7d7Y4RsNhBrRj6yW1rqiObw@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@gmail.com> wrote:
 |
 |> On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <steve@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@gmail.com[/1]> wrote:
 |
 |  [1] mailto:crossd@gmail.com
 |
 ||On Tue, Jul 22, 2025 at 6:27 AM Steve Simon <[2]steve@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@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