Hired: A Modern Take on 'Ed'

by nateb2022 • 2 years ago

65 50 2 years ago

gmfawcett2• 2 years ago

So sidju says to themselves, hey, let's add syntax highlighting to ed. Kids, this is how you break the eternal seals on the hellmouth, and is also why we can't have nice things.

sidju13• 2 years ago

The greatest crime is adding a `help` command and printing errors by default. Fools who stumble into `ed` unprepared should find no solace, it is a crime against the world itself to offer them aid and escape.

gmfawcett2• 2 years ago

So say we all.

(And in case there were any doubts, I applaud your hellmouth seal-breaking invention. Scratch those itches, eternity will take care of itself!)

avgcorrection4• 2 years ago

That’s the same as bat:[1] one of the features is syntax highlighting. Kind of unexpected to find a concatenation program… which also does that.

[1] https://github.com/sharkdp/bat

sidju13• 2 years ago

You wouldn't believe how often I run `bat` to quickly read some source code. It is nearly constantly open on my computer.

It is just so easy to run, easy to use, can open multiple files and is so readable. Why would I open an editor when I'm already in a terminal and it's right there?

teeray• 2 years ago

Are there any ed users that can speak to what they like about it? I have written ed scripts, but actually using it as an editor just felt like vim but with fog of war turned on.

Ferret7446• 2 years ago

It works in dumb terminals. A notable side effect is that it lets you see previous terminal output so you can reference it while you're editing, and use Ctrl-Z and fg to swap back and forth.

(Although usually I prefer to run my shells in Emacs instead)

agumonkey3• 2 years ago

I like fog of war, it keeps me sharp

PhilipRoman• 2 years ago

I've used it once on an embedded device, which had neither ssh nor telnet. Luckily, it had bash available, so I set up something like this:

    /bin/bash <> /dev/tcp/...

With netcat listening my side. Most things kind of worked (no way to send ctrl-c though) but vi couldn't properly redraw it's screen. So I had to use ed.

geocar• 2 years ago

I don’t edit files for no reason, so the context of what I am doing is lost when a screen editor takes over the window; ed/ex keeps that on-screen, which keeps quick edits quick.

I also like being able to see my changes as I work.

avgcorrection4• 2 years ago

This could be pretty useful for writing shorter commit messages (even up to a subject + paragraph). Like a more powerful `cat`.

pram• 2 years ago

Well, it is the standard text editor after all.

sidju13• 2 years ago

The original inspiration was part annoyance at how badly most editor's keybindings map to dvorak and part how modern editors sometimes crash.

With a command based editor you just type commands, no fancy keybindings that get jumbled when you have a different layout.

(And I have plans for writing fired, which is basically hired with a window to see the state of the buffer. It would still be strictly command based though, so not a vim remake.)

sidju13• 2 years ago

Oh, yes. I find ed to be excellently usable since the most common code editing operations are (in my perception) well supported in ed: - moving or copying chunks of code (`m` and `t` commands) - deleting or replacing chunks of code (`d` and `c`) - writing new code (`a` and `i`) - renaming stuff (`s` and `g`) - and rarely, small edits to existing code (`s` and `C` in hired)

As long as you write your code with plenty line-breaks it is often easy to just replace a line to make the change you want, so `s` and `C` are rarely needed (though I am weak and tend to use `C` quite often, for example to get the indentation right when adding lines).

cturner• 2 years ago

It is useful when you have typed some commands, and then want to edit a text file without losing the text. Consider if you are working on text that you will want to copy+paste into a jira/bugzilla ticket as an evidence-of-work. Or if a second person is watching your screen as you work.

It is useful when you are operating over a high-latency connection. As long as you do not send newline by mistake, you can form the command you want to dispatch with confidence. You do not have to worry about where your cursor is, and you won't find yourself in an unexpected mode, or having done the wrong number of undos or redos.

For a while I used it to write C for a hobby-project on the train, using an android phone and screen keyboard. Simple keypresses are easier than control characters in that setting. If you are interacting with a remote unix system from an ipad, you may find it useful for the same reason.

About once a year I find it useful in situations where I have some kind of broken or low-function TTY, or library problems and want to make an edit.

At times, it would be useful to have an ed-like mode available in bash, so that you could have access to an editor when your system was preventing you from spawning new processes.

soveran• 2 years ago

I use it daily. I run a slightly modified version: I added line editing capabilities with linenoise and I use EREs. The most common use case for me is editing with :g/re, which allows me to see only the matching lines. If I want to keep only those lines, I type :v/re/d, and so on. I also invoke it regularly from my main editor when I find it more efficient for modifying some file or some region.

mbivert• 2 years ago

Not a user, but I've decided at some point to use it to write a `.tex` report. Insightful experience:

(i) fixing mistakes is costly: one needs to think more/be more cautious;

(ii) one needs to grow a "mental image" of the codebase;

(iii) which encourages to be more regular and austere/simpler, while training memory;

(iv) the lack of features encourages creativity, e.g. using "good" regexps to navigate the code; a common example is for C functions to be essentially uniquely identified with `^foo\(`, when the functions are defined with:

  int
  foo(…) {
  …

The dumber the tool, the more intelligent the user has to be, and reciprocally. Of course, there are practical limits; that's just the general idea.

iav• 2 years ago

This is in Rust? I was expecting Ed to be in C…

snvzz2• 2 years ago

Same. I was hoping for ISO C99, to maybe port to AmigaOS.

But it's rusty.

rob74• 2 years ago

If you want AmigaOS, maybe you should switch to vim (https://amitopia.com/vim-was-originally-developed-for-the-am...)?

flgstnd2• 2 years ago

i thought i like rust, compiling this program was very weird. it took multiple minutes on full CPU load and even after cargo finished there was still a build process using one CPU core on 100% until i killed it.

sidju13• 2 years ago

That sounds strange. Could you give reproduction instructions? (OS, architecture, rust version) Maybe there's some kind of upstream bug I should report.

breather• 2 years ago

Why make the same mistake twice?

sidju13• 2 years ago

Sorry to disappoint. Would have been difficult to make it this feature rich and have as explicit errors if I wrote it in C.

Reasons for choosing rust were: - Error handling style, easy to include context - Easy to import and use syntax highlighting library - Some level of inherent UTF-8 validation and support - Easier to make the ed-runtime support pluggable IO and UI

swdunlop• 2 years ago

I was expecting electron in there somewhere.

tempodox2• 2 years ago

Came here to say the same. I was fully expecting the irony of seing the world's smallest (and standard) text editor re-implemented in the most infamous bloat monster. Also, every software ever written is being rewritten in Webshit these days anyway.

sidju13• 2 years ago

It isn't too late yet, you can be the one to bring The Standard Editor to the Webshit masses!

The backing library https://github.com/sidju/add-ed could either be run through https://neon-bindings.com/ , or compiled into web assembly for that matter. Should just be a weekend project to create an electron `ed`, and if that isn't sufficiently bloated you can `node install everything`.

GuB-42• 2 years ago

I tried compiling it as suggested by the GitHub page.

The build folder weighs in at 618MB and it took 5 minutes and 139 packages to compile on a decent 2019 machine. The final executable is 84M (debug, 11MB after stripping)

It then takes something like 10MB of RAM for opening an empty file, of which 1MB is on the heap.

It is not Electron, but for an "ed" remake, it is definitely a bloat monster. Overall, it is 100 to 1000 times heavier than "ed".

EDIT: speaking of bloat, I remember when EMACS was nicknamed "Eight Megabytes And Constantly Swapping" as a joke on how bloated it was. Times have changed...

adityaathalye• 2 years ago

You may enjoy Episode 40 of https://lambdaisland.com, published 1 April 2018.

https://www.youtube.com/watch?v=6oPRUzzP9DU

They demonstrate how to build the The Ultimate Dev Setup for mind-blowing Interactive Clojure Development atop the one true, the right honourable, the standard editor, Edward 'ed(1)'.

impoppy2• 2 years ago

This person has delusions of reasonable choices.

sidju13• 2 years ago

Is the delusion that they exist, or regarding what is reasonable?

I'd like to know what kind of deluded I am.

impoppy2• 2 years ago

You just don't like modal editing. Switching from emacs to ed due to emacs' slowness is by no means a reasonable choice considering being limited to line-by-line editing. Ed is bare-bones and over time you will realize that you need other things that majority of other editors have, then add multi-line view support, then many other things. Emacs can be faster with native lisp compilation, but if you are adamant you want to go full bare bones, you'd be happy with nano, which has some subset of Emacs keybindings and supports syntax highlighting. If you call vim (let alone neovim) a monstrosity, you could go for vi or helix. Switching from emacs to ed is a dumb choice and rewriting ed from scratch in Rust with syntax highlighting is another dumb choice, when you could fork the thing - your rewrite doesn't even have 100 commits in 2 years, which probably indicates there's not a lot of innovation going on.

If you just wanted to rewrite ed in Rust - sure, go ahead, but just say it. My point is the reasons for hired you stated do not sound like reasonable choices at all.

projektfu2• 2 years ago

Ed made a lot of sense in the days of teletype terminals.

stevekemp• 2 years ago

I have fond memories of using edlin on MS-DOS 3.x. Similar system, but of course no remote access to the system there.

projektfu2• 2 years ago

As a kid I thought it was insane, the commodore 64 was easier than the IBM PC/AT, but I see how with a hardcopy, you can have your program or document printed in front of you with line numbers, then you just edit as you need.

On a visual terminal it gets hard remembering what's there. I was really relieved they added EDIT to DOS 4.

agumonkey3• 2 years ago

I found myself reading about ed and teco (and qed) the other day, they came from similar contexts/eras and share the same paradigm, but somewhere along the lines they branched out into flamewars :)

sidju13• 2 years ago

It's extremely interesting to read their nearly recognizable syntax and at the same time nearly completely foreign concepts.

In case anyone else wishes to read the qed manual, here is the link I found after a while spent searching: https://wayback.archive-it.org/all/20150203071645/http://cm....

agumonkey3• 2 years ago

thanks for that link :)

ramon156• 2 years ago

This repo is actually a cool real-world example on how to wrap an application. Very neat!

sidju13• 2 years ago

Not sure if there is a misunderstanding here.

I'm not using the original ed binary (though I could have and it would probably have been smarter), I wrote my own full implementation as a library to also change some things that annoyed me.

Hired: A Modern Take on 'Ed'

Related Stories