Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit) (github.com/velorek1)
118 points by velorek 12 hours ago | hide | past | favorite | 30 comments
I set about coding my own version of the classic MS-DOS EDIT.COM for GNU/Linux systems four years ago and it this is where the project is at... still rough around the edges but works well with Termux! :) Demo: https://www.youtube.com/watch?v=H7bneUX_kVA





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.

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


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.

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.

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/>


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

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


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

This look brings back old memories! Great job!

Thank you, I appreciate it :)

vim

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!

Interesting project. Thanks for sharing! :)

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/

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: