Live data from Hacker News

Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

github.com

41–50 of 64 posts

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#41
post #25

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…

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

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#42
post #33
post #25

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…

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.

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

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#44
post #32

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.

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#46
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...

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#47
post #11

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!

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#49

Earlier quoted context omitted.

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

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.

Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)

#50
post #30
post #27

Earlier quoted context omitted.

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.
Post reply on HN