I wrote the world's worst text editor (2020) | Hacker News Reader

I wrote the world's worst text editor (2020)

briancallahan.net

38 pointsAlexeyBrin26 comments

I remember intentionally writing an awful text editor.

A guy had a kid who had severe learning difficulties and motor problems. However he loved typing into the computer but would get frustrated if he hit say alt and would go to the menu, or held a key down too long and get duplicates. Stuff like that. Or would accidentally close it etc.

So i wrote the worlds worst text editor, it would intercept all key presses so that nothing would be handled that would result in the cursor leaving the editor. You could hold down keys as long as you want and would only get one character, same with delete. It also made a type wtiter type noise on every key press. Pretty sure i had timing as well so if you pushed the same key twice quickly you would only get one character output.

It had no menu bar and opened full screen and would start up wherever you left it text wise.

Testing it would drive me mental. It was so frustrating to use! I can't even remember how you exited it as im pretty sure i was intercepting ctrl alt delete. This was windows xp days.

The kid liked it though!

Intercepting ctrl alt delete is supposed to be impossible, though.

Stackoverflow to the rescue - https://stackoverflow.com/a/2435686/723918

You don't need to actually stop ctrl alt del, you just need to stop it from opening task manager!

At that time i was working with kernel hooks a lot. Maybe i used that. I remember even having code to hide stuff from appearing in task manager, or hide files from showing up in file explorer.

I remember debugging this stuff was painful, when it didn't work you got the BSOD.

Be interested to know how much of these techniques could work on win 7/10. Im guessing not at all.

Did the kid accidentally press Ctrl+Alt+Del together so many times that it was an issue to be addressed with a custom kernel driver? It sounds a bit like an overkill. The key combination was intentionally picked to avoid accidental presses. https://en.wikipedia.org/wiki/Control-Alt-Delete#History

It doesn't necessarily need to be intercepted. I remember on Windows 7 I managed to create a small program which opened a screen-filling window with the close button disabled and the "always on top" property. I could press Ctrl+Alt+Del as much as I wanted, the task manager always opened behind my program's window and so was pretty useless. Then again Windows 7 still had some quirks here and there, maybe it's different now.

Ctrl+Alt+Del doesn't open Task Manager directly, it opens a separate full-screen menu that looks like the login screen with options for shutting down, logging out, or opening Task Manager. It's been this way at least since Windows 7, but probably earlier.

Ctrl-Alt-Del, from the old NT days, was a Secure Attention Sequence, theoretically not interceptable short of a kernel driver, and took you to a separate desktop. NT supported separate desktops, but they're not like virtual monitors you see today; they're more like separate virtual ttys in the Linux console sense, entirely separate desktops with wholly detached window environments running on them. That's where the lock screen lived, and where Ctrl-Alt-Del took you to.

Windows 7 probably changed that somewhat. I know the lock screen in Windows 10 is super buggy wrt customisation.

You’d think, but I know of one POS system (in both senses of the term) that managed to do it accidentally. [Edit: on Windows 7, which you’d think would be able to handle stuff like this.] If you scanned a UPC into the quantity field it would lock up the entire OS, to the point that even Ctrl+Alt+Del was ignored and you had to hard-reboot the system. After years of this they finally gave us a patch that still froze the computer, but C+A+D would at least interrupt it. I never did work out how they managed to bungle things that badly.

Control alt del triggers an interrupt. If it is unhandled then nothing happens. If your OS crashes there is nothing to catch interrupts. Maybe the patch fixed the OS so the interrupt handler remains responsive. This is a common problem for a RTOS

This was on Windows 7. (I thought I’d mentioned that, but I guess I forgot.)

This is a great lesson in accessibility and building the right product for a specific user. While you call it "awful" you ended up with something extremely accessible that made your user happy. This is an extreme example, but there is a lot to learn from this

I made an awful line editor in the 1990's, entirely in Bash. It used Bash arrays to buffer the text.

There is a surviving piece of it: a line editing routine. For many years, that was included in GNU Bash as one of the examples:

https://git.savannah.gnu.org/cgit/bash.git/tree/examples/scr...

They had the good sense to remove that.

This frankly isn't too far off what text editing was like in the 60s and 70s. TECO and ed evolved into visual editors but initially were pretty much like this, including specific commands to print out the neighborhood of the insertion point (or other span). Otherwise you edited blind.

EDLIN was the only built-in text editor in MS-DOS until EDIT.COM appeared in 5.0. It was also based on ed.

If it doesn't create a new attack surface by rendering HTML unprompted, it can't be that bad.

This does sound truly awful!

If we're going for a truly minimal, Unix-style, modular program though, why not abandon the focus on lines and have it operate only on a single character? You could have it accept text as a parameter, and return the edited text as the result so then you could write multi-character strings by piping together multiple invocations of the program!

I wrote one in gwbasic for my dads 286 when i was a kid. Fixed number of lines, no saving-just print to paper instead, once you pressed enter a line couldn’t change again. Dad actually used it to write some letters. At as this was the worst editor i ever made, and i loved it.

So, what does TECO do when you type your name into it? :-)

(I still use /bin/ed instead of . . . certain other editors I will not name here. Mercifully, all of my TECO "skills" have fled).

As the new kid on the block, I skipped TECO for KED (which I have a soft spot for to this day). Sometime around '85, had to write a VT100 emulator for some newfangled Z80 box just so it could be used it as a terminal for my personal PDP-11.

In the 90s I wrote a simple editor with a UI for a project. I had no idea how hard it was to this in a performant way. Cost me a few weeks of sleep but learned a lot.

If you write a program that can write out text files, do not test it on its own source code.

Trust me on this.

git checkout editor.ext

(this is not about VI)

I hurried thought to be a confession of the creator of the VI

More apropos would be "this is not about `mg`" (the tiny Emacs clone that is part of the OpenBSD base install).

Because the author is (was?) the maintainer of `mg`.

Reply on news.ycombinator.com