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.
Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
51–60 of 64 posts
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#52Looks 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.
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#53Very 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
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#54I 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
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#55Earlier quoted context omitted.
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.
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#56The 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>
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#57Earlier quoted context omitted.
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.
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#58Apart 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.
Thanks for recommending libgrapheme. I am honoured, being the author of this library.
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#59Earlier quoted context omitted.
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.
Re: Show HN: A retro terminal text editor for GNU/Linux coded in C (C-edit)
#60Earlier quoted context omitted.
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.
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.