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.
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.
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?
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)'.
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.
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.
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.)
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).
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.
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)
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.
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.
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.
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.
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...
Most of the initial data on the heap is all of the embedded pre-formatted syntax definitions, which I decided was a small price to pay for a quicker startup (and since `cargo install` is unable to include any bundled syntax definitions).
Aside from that I guess I have included some pretty big libraries, which due to static linking basically add directly to the binary size. I'm open to replacing most of them for smaller versions, but I won't do it myself.
When I checked the memory usage I saw that bash is using 11 MB and hired 9.2MB, so I'm pretty satisfied with that. If you want some memory usage horror though, note that due to having unlimited undo/redo hired will constantly increase its memory usage for every change you make until you close it. (It is at least diff-based, so it doesn't blow up on larger files unless you change every line.)
Yep, decidedly a different time. Very different expectations about what functionality should be expected in a tool, and when it is meaningful to try to reduce memory usage.
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`.
I was going to say that I expected the Webshit version to use different NPM packages for cursor-blink-on, cursor-blink-off, and cursor-blink-toggle (not to mention telemetry and the requirement to create a cloud user account), but it seemed out of context :)
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 :)
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
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.
That sounds strange. Could you give reproduction instructions? (OS, architecture, rust version)
Maybe there's some kind of upstream bug I should report.
I used x86_64 GNU/Linux, NixOS, cargo 1.78.0-nightly (ccc84ccec 2024-02-07).
When deleting the target directory and running `cargo build`, all the dependency crates build pretty fast. But then the build script takes ages. And somehow runs twice.
In the target/debug/build dir are 2 different build-script-build executables, that produce the same outputs (compressed_syntaxes/theme).
I thought it might be related to the `cargo:rerun-if-changed` stuff in the build.rs but it's the same with those lines commented out.
I can confirm that it created two binaries of basically every dependency and I don't know why (tried to look into it but couldn't find anything), but at least in my case both don't run. (I looked at the running process ID and command line while reproducing. It was the same binary running in the same process the whole time for me.)
There is a bit of a gotcha that if you build a debug build the build script will be less optimized. This makes a debug build take nearly 4 minutes total on my computer due to how much processing is done in the build script. A release build only takes roughly 2 minutes total due to the optimized build script.
(The "cargo:rerun-if-changed" tells cargo under which circumstances it is necessary to rerun the build script. It doesn't change its behavior on a fresh build.)
Please check if it really does run twice, and thus changes process ID and command line. (I run `top`, press shift+v for process tree, c for command line and go look at the cargo process to find the build-script run.)
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.
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.
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.
You seem to misunderstand "freezing up on me" to be about slowness, that was a crash leaving the window open that occurred every so often for me despite a relatively simple emacs setup. My initial frustration resided in the complexity of emacs and vim and the many potential failure points that come from that, wherefore I looked into simpler historical editors and ended up trying out ed. (I considered vi, but decided that ed was a good first step if I went there anyways.)
I didn't blindly decide to switch to ed, I tried it out and found its commands to suit my editing methodology, the lack of keybindings to help make it work well on dvorak and the line editing workflow to save me from often manually moving my cursor "long distances". Due to how much I liked the concept I wanted to make improvements.
(I have also looked into vi but I don't quite like the cursor focused way of working it entails, and really dislike how it depends on keybindings (at least hjkl).)
Regarding why I rewrote it rather than forking the C repo you can look into my other comment that explains what I gained from it. And of course I did it because I wanted to, it's not like I'm getting paid for this.
It is well established that commits aren't a great way to judge anything, and innovation is especially hard to judge by any metric. Feel free to look at the usage documentation for add-ed https://docs.rs/add-ed/latest/add_ed/ if you wish to quickly gather some insight into the design, to base your judgement upon.
(btw, some corrections
ed arguably is a modal editor with default command mode and an input mode entered by `a` and `i` and left with either ctrl+c or a lone `.` on a line.
The hired repo has around 100 commits since it is only the syntax highlighting UI, CLI and config handling; the `ed` runtime implementation is in https://github.com/sidju/add-ed with around 200 commits.
Good grief, there’s no need to be so mean about it, there’s nothing wrong with this person building a simple tool to suit their needs. Linus has his own hacked-up editor and few would call him dumb.
