Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Text Editor Data Structures

cdacamar.github.io

Post reply on HN
Print view View original

21–30 of 81 posts

Re: Text Editor Data Structures

#21

Post by scelerat »

eschneider wrote: post #4
mannyv wrote: post #2

Apple's MPW was Apple's programming environment for a long time. It's been a while, but I believe that it represented everything in a tree of n-character chunks (n = 6?). It was probably the first editor that I used that could open files of pretty much any length.

I do miss the 'select and execute', and 'everything is a shell' model of MPW. Definitely one of my favorite development environments.

elsewhere on HN today is a short article on BBedit, which has a really nice shell worksheet interface similar to the old MPW. Select the text you want to execute, hit control-return, and the shell output will appear below the selected text.

Re: Text Editor Data Structures

#22

Post by z3t4 »

KerrAvon wrote: post #6
badsectoracula wrote: post #5

There are tons of articles about plain text editor data structures, but what about rich text editor data structures? Let's say i want to implement a text editor that can have bold, italic, underline, etc text but also be able to do automatic word breaking, align paragraph text to left/middle/right, insert images and/or other objects, have floating images and/or other objects around which the other (non floating) text…

It's not actually that different or complicated if you're already doing proportional plaintext rendering -- you need to store style attributes for a range of text, and you need to support different heights per line. The real complexity is rendering all of unicode properly, and supporting international fonts, bidi layout, vertical text, etc.

You don't need any fancy data structures. 95% of the performance goes into glyph rendering. And with Unicode the performance gain from monospace fonts goes out the window as some Unicode characters are very large, and not only that they also take up many bytes. So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. You also need to read ahead as there are combination characters, for example a smiley combined with the color brow becomes a brown smiley. I've blogged about implement support for Unicode in an editor here: https://xn--zta-qla.com//en/blog/editor10.htm

Re: Text Editor Data Structures

#23

Post by kjs3 »

badsectoracula wrote: post #5

There are tons of articles about plain text editor data structures, but what about rich text editor data structures? Let's say i want to implement a text editor that can have bold, italic, underline, etc text but also be able to do automatic word breaking, align paragraph text to left/middle/right, insert images and/or other objects, have floating images and/or other objects around which the other (non floating) text…

Perhaps look at how (Open,Libre)Office does it to support ODT format (e.g. OASIS Open Document Format)?

Re: Text Editor Data Structures

#24

Post by thangalin »

badsectoracula wrote: post #5

There are tons of articles about plain text editor data structures, but what about rich text editor data structures? Let's say i want to implement a text editor that can have bold, italic, underline, etc text but also be able to do automatic word breaking, align paragraph text to left/middle/right, insert images and/or other objects, have floating images and/or other objects around which the other (non floating) text…

RichTeXtFX[1] has these abilities[2] along with demo code[3] that provides an entry point for sleuthing. My text editor, KeenWrite[4], uses RichTeXtFX, but takes a different approach due to its usage of inline variable references. Rather than edit the document in a WYSIWYG-like fashion, users edit the Markdown document as plain text then export as PDF by selecting a theme to apply for typesetting. This cleanly separates content from presentation. The "themes" video tutorial demonstrates how theme selection works.[5]

[1]: https://github.com/FXMisc/RichTextFX/tree/master/richtextfx/...

[2]: https://gluonhq.com/presenting-a-new-richtextarea-control/

[3]: https://github.com/gluonhq/rich-text-area/blob/master/sample...

[4]: https://github.com/DaveJarvis/keenwrite

[5]: https://www.youtube.com/watch?v=3QpX70O5S30&list=PLB-WIt1cZY...

Re: Text Editor Data Structures

#25

Post by rcoveson »

z3t4 wrote: post #22
KerrAvon wrote: post #6

Earlier quoted context omitted.

It's not actually that different or complicated if you're already doing proportional plaintext rendering -- you need to store style attributes for a range of text, and you need to support different heights per line. The real complexity is rendering all of unicode properly, and supporting international fonts, bidi layout, vertical text, etc.

You don't need any fancy data structures. 95% of the performance goes into glyph rendering. And with Unicode the performance gain from monospace fonts goes out the window as some Unicode characters are very large, and not only that they also take up many bytes. So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. You also need to read ahead as there are combination cha…

> So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters.

5 bytes? In what encoding?

Re: Text Editor Data Structures

#26

Post by jychang »

rcoveson wrote: post #25
z3t4 wrote: post #22

Earlier quoted context omitted.

You don't need any fancy data structures. 95% of the performance goes into glyph rendering. And with Unicode the performance gain from monospace fonts goes out the window as some Unicode characters are very large, and not only that they also take up many bytes. So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. You also need to read ahead as there are combination cha…

> So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. 5 bytes? In what encoding?

Emojis with skin color, mostly

Re: Text Editor Data Structures

#27

Post by rcoveson »

jychang wrote: post #26
rcoveson wrote: post #25

Earlier quoted context omitted.

> So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. 5 bytes? In what encoding?

Emojis with skin color, mostly

No, that's a ZWJ sequence. Those can be arbitrarily long. Doesn't explain where "5 bytes" comes from.

Re: Text Editor Data Structures

#28

Post by lelanthran »

rcoveson wrote: post #25
z3t4 wrote: post #22

Earlier quoted context omitted.

You don't need any fancy data structures. 95% of the performance goes into glyph rendering. And with Unicode the performance gain from monospace fonts goes out the window as some Unicode characters are very large, and not only that they also take up many bytes. So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. You also need to read ahead as there are combination cha…

> So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. 5 bytes? In what encoding?

> 5 bytes? In what encoding?

I believe UTF-8 reserved up to six bytes for a single character.

Re: Text Editor Data Structures

#29

Post by [deleted] »

phildenhoff wrote: post #19

Thanks to this article, I learned that the core data structure for VSCode's text is written in TypeScript[0]. I, uh, I knew VS Code was written in TypeScript but I didn't realise _all_ of it was. It's crazy to think that the editor works as well as it does! [0]: https://github.com/microsoft/vscode/tree/main/src/vs/editor/...

[deleted]

Re: Text Editor Data Structures

#30

Post by WorldMaker »

rcoveson wrote: post #25
z3t4 wrote: post #22

Earlier quoted context omitted.

You don't need any fancy data structures. 95% of the performance goes into glyph rendering. And with Unicode the performance gain from monospace fonts goes out the window as some Unicode characters are very large, and not only that they also take up many bytes. So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. You also need to read ahead as there are combination cha…

> So one Unicode character can be up to 5 bytes long and take up the same canvas space as 3 characters. 5 bytes? In what encoding?

Some "single character" emoji easily exceed 5 bytes in all encodings. You may think ZWJ sequences are cheating, but emoji isn't the only language encoded in Unicode with complex ZWJ sequences.
Post reply on HN