I kind of feel like this video is my first and last comment on AI-assisted coding--or lack thereof. Namely, I coded the whole-ass Lox programming language presented in the 2nd half of Crafting Interpreters from scratch using nothing more than Rust and ed(1). Every keystroke. By myself. And I enjoyed the hell out of it.

youtube.com/watch?v=Rou26TpUG0Y

Show thread

@me

Depending on your platform, you might have xclip instead (similar functionality on X), pbcopy/pbpaste on OSX, or some similar tool on Wayland or Windows.

@me

Using temporary/transient storage can avoid the temp-file cleanup step though:

w | xsel -ib
,d
r !xsel -ob | rot13

or

w ! tmux loadb -
,d
r !tmux showb | rot13

Ameliorates it by a wee bit, but still a hassle that I'd fix if I had a time machine :flan_XD:

@me

For just capturing the output of a command, you can use:

r !somecommand

But if you want to filter a range of lines through an external filter with POSIX ed(1), you need some sort of temporary storage (whether a file, the system clipboard, a tmux buffer or whatever). There's no analog to

:10,20! rot13

offered by vi/vim.

Someone (can't find the post/author at the moment) did hack this functionality into ed, but it's a custom fork of POSIX functionality.

So, I have a question for the ed(1) crowd:

Is there a way to do the following:

w !somecommand >tempfile
r tempfile

Without having to use an intermediary file to capture the output of the command?

#AskFedi #ed #ed1 #unix

Had a weird dream last night where a few friends were asking me to help them install and start using ed(1), the standard Unix line-oriented editor.

With autumn officially here in the northern hemisphere. that means it's pumpkin-spice $EDITOR season:

$ ed -p "🎃 " file.txt

A simplified history of regular expressions:

- In 1951, Stephen Kleene invented regular expressions.

- In 1966, Ken Thompson built the first software implementation of regular expressions, in the QED text editor for CTSS. UNIX ed is a cut down version of QED, popularizing the tradition of regular expressions in editors. grep started as a standalone version of the engine from ed. em, ex, vi, and vim evolved from ed.

- In 1987, Larry Wall spread regular expressions to the next generation of programmers through Perl. Gravely, it uses backtracking, spreading terrible performance for decades. It derives its engine from the rn newsreader, which derives it from Gosling Emacs. James Gosling told me he wrote it from scratch.

- In 2010, Russ Cox, having spent time at Bell Labs, rejected backtracking and built RE2, a fast and scalable engine, generalized from work on Google Code Search. Its ideas have spread to Go regexp and Rust regex, a new generation of engines. These engines dynamically select between specialized matchers, depending on the pattern.

- Since 2025, Ian Erik Varatalu has been researching regular expressions for his PhD and has produced a fast engine using symbolic derivatives. It implements seldom-included intersection and complement and efficiently implements lookaround, which had been exclusive to backtracking engines.

#unix #computerscience

Show thread

@cks Yes we also had way too many users on that poor old PDP-11/45 so no screen editors. I got really good at 'ed'. Sad since I had used EDT on a VT-100 and that editor was sweet!

@aartaka

I just tested ex(1) on both FreeBSD-ex and Vim-ex-mode and both treat a newline as scroll-one-line. But the others are reasonable critiques.

I learned today that POSIX specifies a tool designed to assist you in reviewing & modifying LLM-generated code. In typical Unix fashion, they shortened "reviewing & modifying" to just two letters:

$ rm code.rs

It even has command-line options to [r]ecursively [f]ix whole directories of LLM-generated code:

$ rm -rf project/

@aartaka

ex(1) should still maintain most of the flexible addressing of ed(1). I'm curious what you've identified as missing.

Some variants of ex have the unfeature of sending ti/te codes to switch to/from the alternate screen, removing a key ed benefit of seeing output of previous programs as context for your editing.

And ex does add the ability to filter a range of lines through an external program,

`:'a,'b! rot13

a key feature missing from POSIX ed.

@dougmerritt

@misterdave

To be fair, ed(1) will show you the text in your file...you just have to tell it that's what you want (and optionally which part of the text you want to see and how you want to see it -- plain, numbered, unambiguous, or run through a filter).

@gsuberland

It’s interesting that, as time passes, I grow my assortment of ed(1) scripts that optimize my workflows. Scripts that are not transferrable to e.g. #Emacs. But easy to write and integrate in The True Unix Editor.

These scripts are really useful, like an interactive narrowing grep I just wrote!

So I have perfect scripts and ed(1) versus Turing-complete Emacs and useless vi(m).

As time passes, I seem to gravitate towards ed(1).

Let’s see where that gets me.

CC @ed1conf

I got #linux 7.2 booting on my #Palm IIIxe and #Handspring #Visor! #nommu now to get my graffiti workalike working properly. (The stowaway keyboard works great for now. #ed is perfect on the 32x20 char fbcon) #busybox #buildroot. (See github.com/jsmemfault/uclinux)

Show older
BSD Network

bsd.network is a *BSD-adjacent Mastodon Instance. We have a code of conduct.