Apart from the learning experience, there is still value in a small-sized, fast TUI text editor for Linux.

However, my two suggestions would be:

- add Unicode support (it's the 21st century, so ∑, ®, etc. should finally work); this is not easy, but the earlier you do it the less dramatic the changes will be (check out https://github.com/unicode-org/icu/tree/main/icu4c);

- don't allocate the lines individually (as you do now with malloc, having looked at the code); at least use an arena allocator, i.e. allocate larger chunks of memory and the provide your own alloc_line function that uses the larger chunks (called arenas) piecemeal. This will speed things up and reduce fragmentation. A more advanced approach would be not to use per-line buffers but to switch to rope data structures e.g. https://github.com/josephg/librope).

As an alternative to ICU, there is suckless's libgrapheme (https://libs.suckless.org/libgrapheme/) which is more than a 100x smaller and provides full Unicode compatibility.

Heh, I maintain the MacPorts port for this lib! Like all suckless projects, it’s written in very simple and portable C which makes it a breeze to package.

https://ports.macports.org/port/libgrapheme/

Thanks for your work on packaging my library. Please let me know if I can make the process simpler for you; I take great care to make packaging as simple as possible for the packagers. Likewise I have no sympathy for those writing software that is almost deliberately hard to package.

Thank you for your work on the library! It really couldn’t be easier to package but thank you <3

Thanks for recommending libgrapheme. I am honoured, being the author of this library.

Interesting. Cool library, I'll check it out. :) Thanks for sharing

Are there any similar options that handle collation and normalisation? No small Unicode library seems to implement them, unfortunately.

Author of libgrapheme here: Both collation and normalisation are non-trivial and have many gotchas thanks to the way the Unicode consortium likes to write their specifications. I sometimes get the feeling that they don't even care about implementers and just document what is done in the reference implementation ICU.

The only sensible normalisation one can implement is the full decomposition (NFD), and maybe the full composition (NFC). You rely on the full decomposition if you want to collate correctly, which is a problem because the amount of memory needed to store the decomposition is unbounded in general. I don't want to make the libgrapheme users jump through hoops, and I also don't want to do any memory allocations in libgrapheme either.

There is an idea floating in my head on how to solve this, but I'm currently busy finalising Unicode 15.1 support (Unicode 16.0, released on the 10th, will be trivial to upgrade to) and releasing my already fully-compliant implementation of the Unicode bidirectional algorithm.

I see, thanks for replying. I agree, Unicode specs are hell to work with (I tried doing a auto-codegen thing based on them and just gave up due to the size of tables generated and the seemingly-arbitrary edge cases). libgrapheme looks pretty good otherwise, I'll keep an eye on it for whenever I have to wrangle with Unicode on a low level again (hopefully not for a long time).

> This will speed things up and reduce fragmentation

Does this really make much of a practical difference these last decades? I wrote a text editor back in the late 90s in DOS using DJGPP with per-line allocation and it worked fine on the Pentium MMX i had at the time (and my approach to optimization at that time was be ignorant of the concept :-P), i'm not sure it'd really make much of a difference on any desktop or laptop CPU released past 2000 - at least as far as users editing text files are concerned (might make a difference if you try to open a multiGB file with barely a line break and accidentally press a letter :-P).

No, it won't. You might want an arena for other reasons (better reasoning about lifetimes, preventing nest of pointers, etc.), but an array of line array approach to text editors is totally valid (except in the case of millions of extremely small lines).

I do from time to time open files of millions of small lines. To this day vim handles it better than emacs. These would be log files.

Log files have lines that are long enough, I was thinking more of one/two-character long lines (such that the overhead of malloc bookkeeping would be more than the line size in memory). Regardless, Emacs also stores the data in a single array with a gap in middle (and memcpy is relatively cheap), so what slows it down is probably not the choice of data structure but everything else built around it.

Yeah I have very high limits for paren matching and syntax highlighting so probably those scanners.

I agree. Unicode support is top priority. Thank you for sharing those links.

Well yeah, Seph is right as usual I’ve been updating my MLIR generation code to use Twine lately: https://llvm.org/doxygen/classllvm_1_1Twine.html#details

LLVM has been using rope data structures for some time. There is more discussion about it here:

https://lists.llvm.org/pipermail/llvm-dev/2011-July/041639.h...

In my situation when parsing lines of code Twine stores the file path and concats the line number and column when getting the location within a file. It does this a lot so using Twine there really helps. The rope data structure can be used in a number of ways.

When you mentioned retro I was expecting something like editline. Now I feel old.

Anyways, the TUI on mainstream MS-DOS 6.22 and Borland from those days were incomparable to anything on mainstream Linux even on these days. For some reason Linux is the king of text mode and yet never had a proper TUI tradition.

Thank you for sharing the project. Compiled well on my side, looking forward to the next developments. My (unrequested) feedback:

+ consider renaming from C-edit (uppercase) to lower case c-edit, because it is simpler to type from the terminal.

+ the animations of the spining part on top was distracting

+ some menus missing to implement functionality, didn't test copy&paste

+ mouse support would be nice, albeit optional but would complete the MS-DOS 6.22 / borland style since it supported mouse there too

Thank you.

Glad it compiled! Most of your suggestions are on my to-do list indeed. I wanted to maintain an animation to demonstrate that it could be kept running throughout all the different dialogs and listboxes. I'll probably end up changing it. Thank you for testing it. :)

I have to say that when I saw retro I expected ncurses support. Not all retro terminals understand VT100 escape sequences ;-)

What about those who use VT-52 terminals?

Unless you’re using an actual hardware VT52, then it’s pretty safe to assume VT100 support these days.

I concede most physical terminals still alive will have some form of VT100 emulation (up to VT500-level, usually), but half the fun is to make something that can actually run on ancient hardware.

Yeah i know what you mean. I sometimes get that impulse too.

We have 50 years or so of Unix history to honour. We shouldn’t do any less than that.

Makes good sense. Keep up the good work!

Love the look, definitely throwing me back to the halcyon QBasic days.

Slightly related but another way to simulate a retro text editor (old school raster style green screen aesthetic in this instance) is to combine the "cool-retro-term" terminal with the minimal editor "micro".

https://github.com/Swordfish90/cool-retro-term

https://github.com/zyedidia/micro

I love cool-retro-term, I keep it running with a Matrix style terminal toy as a "screensaver" on the small PC sitting on my homelab. It's an ostentatious waste of power and CPU cycles but I appreciate the aesthetics of it.

I'd kill for a way to apply CRT's filters to my vscode editor...

The Craft of Text Editing¹ should be required reading for everybody who wants to write a new text editor.

1. <https://www.finseth.com/craft/>

I didn't know about this resource. Thank you for sharing. I had only seen this one https://viewsourcecode.org/snaptoken/kilo/ I did notice that all editors modeled after this tutorial tended to be clones. That's why I opted for a trial-and-error approach as a learning experience.

See also: EMACS: The Extensible, Customizable Display Editor <https://www.gnu.org/software/emacs/emacs-paper.html> from 1981, by Richard Stallman – the main author of Emacs – as a more Emacs-specific resource.

Or Theory and practice of text editors, or, A cookbook for an Emacs, the original thesis written by Craig A. Finseth in 1980 before he wrote the book I originally linked to: <https://dspace.mit.edu/handle/1721.1/15905>

Going sort of the other way, making an X version of a Borland-like ui, a long time ago I liked XWPE for a while. Even built it for SCO.

It seems like an interesting project as well! I'd love to see it one day

I didn't realize there weren't any screenshots anywhere. I'll make a few, assuming it still even builds. I haven't used it since '99. It was neat but really not exactly a productivity tool today!

Very cool!

I've also been writing my own terminal text editor for a while (just crossed the ten years mark!), so I know how much dedication this takes. :-)

One thing I did recently was start writing the lessons I've learned in my journey, I figured I'd share it in case it helps you, maybe you'll find one or two ideas interesting: https://github.com/alefore/weblog/blob/master/edge-lessons.m...

I wasn't able to compile edge for some reason but it looks cool :). I'll try to do it again when I have some free time. Thank you for sharing your insights. I totally understand what you say about the dedication part, especially when it comes to projects becoming bigger and bigger through the years. It's hard to keep focused and not get overwhelmed at some point

I have added cedit in exaequOS: https://exaequos.com/?a=/usr/bin/cedit ! It compiled successfully with no change. Still buggy, I need to investigate and fix

Cool! This other project of mine (1) is a more finished product and might be better for testing. It's a terminal periodic table with the same display principles as C-edit but should be less buggy. (1) https://github.com/velorek1/terminalperiodictable

Despite being developed in 2010s-2020s, the codebase gives those warm 1980s vibes. Microcomputers, endless possibilities, bright future ahead. What a departure from the modern world of doom.

QB64 is an EDIT.COM-style IDE and a compiler for QuickBasic .BAS programs: https://github.com/QB64Official/qb64#usage

There's a QBjs, for QuickBasic on the web.

There's a QB64 vscode extension: https://github.com/QB64Official/vscode

Textual has a MarkdownViewer TUI control with syntax highlighting and a file tree in a side panel like NERDtree, but not yet a markdown editor.

QuickBasic was my first programming language and EDIT.COM was my first IDE. I love going back down memory lane, thanks!

Same. `edit` to edit. These days perhaps not coincidentally I have a script called `e` for edit that opens vim: https://github.com/westurner/dotfiles/blob/develop/scripts/e

GORILLA.BAS! https://en.wikipedia.org/wiki/Gorillas_(video_game)

gorilla.bas with dosbox in html: https://archive.org/details/GorillasQbasic

rewritten with jquery: https://github.com/theraccoonbear/BrowserGORILLAS.BAS/blob/m...

Basically the same thing but for learning, except you can't change the constants in the simulator by editing the source of the game with Ctrl-C and running it with F5:

- PHET > Projectile Data Lab https://phet.colorado.edu/en/simulations/projectile-data-lab

- sensorcraft is like minecraft but in python with pyglet for OpenGL 3D; self.add_block(), gravity, ai, circuits: https://sensorcraft.readthedocs.io/en/stable/

Interesting project. Thanks for sharing! :)

This is awesome, for the past few months I’ve wondered why there was nothing like edit for Linux and now we have it, great.

I will try to compile it for https://exaequos.com !

Looks great! Makes me nostalgic for when I spent my days as a kid in QEdit.

https://winworldpc.com/product/qedit/30

Oh wow, that's a name I've not heard in a long time.

Looks like the author of that released the larger editor (semware editor) for free https://www.semware.com/ some time ago. That was always the more expensive editor the kid version of me couldn't afford.

This look brings back old memories! Great job!

Thank you, I appreciate it :)

It would be nice to have one like this (full screen) for Windows

Yes, I would like to make a cross-platform editor one day. I would probably choose Pascal's RTL video unit over C for that task. There is one editor called YEDIT that fits the brief for windows systems: http://www.malsmith.net/edit/

vim

vim FTW! :D

FYI The classical Borland text user inteface (TUI) framework used in Turbo Pascal and other terminal MS-DOS editors is open source.

Turbo Vision: https://github.com/magiblot/tvision

The sense of nostalgia this evokes is so strong, thank you for sharing this!

that's cool! so this is the turbo-* vision part, but the *-pascal part is not included?

is there one of those anybody knows about? I have the source to a turbo pascal BRIDGE.PAS card game player I used to enjoy playing. (it's not a good bridge player and it has a scoring bug, but I know how to fix it, and I can run it in dosbox if I want so I'm not desperate in that sense, but I'd rather run native)

Free Pascal comes with Free Vision. FV has some weird history in that Borland released their C++ conversion of Turbo Vision to public domain, then someone converted that to Turbo Pascal and converted it to use graphics instead of textmode (with coordinates in pixels, etc) and then it was ported to Free Pascal and converted back to text mode and to use Free Pascal's cross platform text mode units. The Free Pascal IDE that comes with the compiler is made using Free Vision and Free Vision works on pretty much any platform Free Pascal itself supports (as long as it has some form of text mode).

Regardless of the history, the API is basically the same, you can even read a tutorial written for Turbo Vision and apply it to Free Pascal with minimal changes.

Recently there has been a UTF-8 version (original TP -and FV- was made for 8bit DOS character codes) though it is a big buggy and slower than the non-UTF-8 version. I tried to use to make an Info viewer[0] some months ago but i had to switch to the non-UTF-8 version due to the bugs.

[0] https://i.imgur.com/Qvkt3W0.png

It's awesome. Free Pascal IDE is based on this I think. It certainly something to aspire to :) thanks for sharing

It isn't, Free Vision (Free Pascal's own Turbo Vision library) has a much more weird history though it is indirectly based on the C++ code Borland released back in the 90s, like the version linked here (see my other comment). They have a common ancestor but they are different "branches".

I see, thanks for the clarification. Btw, I really enjoyed YT "Making a game in Free Pascal" back in the day. I did learn a lot from your video :) Pascal is one of my top languages to code in! Nice to see you around here

You just made me realize it has been 10 years since that video :-P. It has been a while since i made a similar video (last one was 'Making a game in Linux using Lazarus' from 6 years ago, most of my more recent videos are random clips from random stuff i work on). Perhaps i'll try making a new one at some point.

[0] https://www.youtube.com/watch?v=s_01Xhd2EJM