The notion of email client itself is gone at this point, everything changed.
I just go so mad. SO MAD.
My reaction exactly :-) But then I thought, everyone has a right to entertain their own misconceptions about reality. Even the guy who write a text editor in between maintaining a major piece of Internet infrastructure :-)
Huh? Are you saying that banjo is still normally thought of as part of an email client? Or that it was never part of an email client?
Pretty cool. It’s easy to forget how fun it is to throw something together for fun without any expectation of serious use.
Here’s mine in under 700 lines: https://gitlab.com/technomancy/bussard/blob/master/ship/editor.lua
Supports multiple buffers, rudimentary auto-indentation, undo, kill ring, and rebindable keys with user-definable modes. No search/replace or syntax highlighting yet.
Of course it’s not much use without user-level config to expose basic commands: https://gitlab.com/technomancy/bussard/blob/master/data/src/edit
Since it’s programmable in userspace, it can also be configured to treat a buffer as a Lua REPL with input history: https://gitlab.com/technomancy/bussard/blob/master/data/src/edit Oddly the hardest part of getting this working was making the prompt read-only.
antirez was sorta-/kinda- ahead of you with LOAD81 tho', cool story bro .. :)
Sure, if you don’t care about the whole “Emacs, but in spaaaaace” angle.
Here’s a ~1000ish line editor I wrote a little while back, with the quirk that it’s a pixel-accurate emulation of QBasic: https://github.com/kivikakk/kyuubey
Kind of impressed that it doesn’t require ncurses - I’ll definitely have to look into that at some point. I’ve been half working on a sub-1K sloc text-editor recently too: https://github.com/charles-l/pep (I don’t have syntax highlighting yet, but I have implemented search and piping out to external processes). Always fun to see small, nicely written C projects, though.
As an API, ncurses has very little to offer; it amounts to little more than a wrapper around the cursor & graphic manipulation codes on your terminal, with the added trick that it also works with glass terminals from the 70s (assuming your database of terminal incompatibility has the right entries, and the environment variable is set right..)
I wrote my own editor which assumes a POSIX system and a terminal with a sane subset of ANSI standard escapes, or any terminal emulator not older than about 30 years. The terminal handling code is around a dozen lines of C to manipulate the termios structure to disable canonical mode input processing, plus a handful of macro wrappers around the ANSI escapes, plus a few more to handle sigwinch.
I really don’t know why people always think “ncurses” when they see a TUI application. It adds very little, and it breaks a lot. Connect to an older solaris system while running rxvt-unicode. Oh, everything is broken now? Quick, find the terminfo file, compile it, put it in the right place (you know how to do all that, don’t you?).. and then cry because “rxvt-unicode” is too long a string for that implementation to handle. The fun thing is, if they assumed you support some standard escapes, most of the things would just work.
It should be noted that this is not antirez' first “editor from scratch”. Those of us who love anitrez for his LOAD81 antics know that there is some wisdom behind this subject ..
I wrote a text editor in C and GTK - about 300 lines. Leverage what’s out there, don’t reinvent the wheel. GTK uses Ropes, which fulfills majority of use cases.
These types of editors though are fairly useless. Scriptable editors like Sublime, Emacs, Vim, etc are way more valuable.
I don’t think he was trying to create a “useful” editor.
True, his ‘useful’ editor is actually LOAD81:
If it can edit text, by definition it is not “fairly useless”. In fact, it does its job pretty precisely.
Meh, so simple, could have done it in one line:
Seriously though, very cool. :)