Live data from Hacker News

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

github.com

21–30 of 64 posts

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

#21
post #16

Earlier quoted context omitted.

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

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

#22
post #19

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

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

Makes good sense. Keep up the good work!

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

#24

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!

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

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

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

#27
post #19

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

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?

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

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

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

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

#30
post #27
post #19

Earlier quoted context omitted.

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