sidju

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.

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'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....

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`.

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.

)

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

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

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.)

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?

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).

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.

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

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

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.)