Live data from Hacker News

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

github.com

61–64 of 64 posts

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

#61
post #49

Earlier quoted context omitted.

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.

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

#62
post #60

Earlier quoted context omitted.

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…

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

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

#63
post #49

Earlier quoted context omitted.

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.

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

#64
post #59

Earlier quoted context omitted.

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