The story about line wrapping is mainly that, you:

  · Break the text into runs.
  · Calculate BiDi at paragraph level.
  · Shape every run to get its length and possible line breaking points.
  · Arrange the runs (now only have length, height, text isnide it and some breaking properties — glyphs and glyph positions are dropped) into lines.

Such process is called “measuring”. And the real text display is delayed until a line become visible: you fetch out the text runs in the line and do the real display.

In most times (like appending text) you do not to do much recalculation.

Let me count all the features that a proper rich text box should support:

  · Input methods, including...  
    · Composing IME  
    · Speech  
    · Handwriting  
    · Emoji picker  
  · Complex text rendering, including...  
    · Bidi  
    · Shaping  
    · Complex-script-aware editing  
    · Complex-script-aware find, replace, etc.  
  · Accessibility

And what they can choose to support:

  · Advanced typography, including...  
    · About line breaking...  
      · Hyphenation  
      · Optimized line break (Knuth-plass, etc.)  
    · About microtypography  
      · OpenType features (ligatures, etc.)  
      · OpenType variations  
      · Multiple master fonts  
      · Proper font fallback ← It is not a simple lookup-at-each-character process  
    · Advanced Middle East features, including...  
      · Kashida  
    · Advanced Far East features, including...  
      · Kinsoku Shori  
      · Auto space insertion  
      · Kumimoji  
      · Warichu  
      · Ruby  
    · Proper vertical layout, including...  
      · Yoko-in-Tate  
  · Inline objects and paragraph-like objects, including...  
    · Images  
    · Hyperlinks  
    · Math equations ← This is really hard.

I don't see any references to things like HarfBuzz or DWRITE, which are NECESSARY to properly display any scripts that's not European. All properly implemented text editors are rich text — because you will need to support font fallback and BiDi and all the Unicode complexity

You absolutely don't need any of these for a tutorial text editor... Those are all things you can hook-in later, after you've understood how to make text editors...

Did you see that this is a command line app (like VI, or EMACS)? Those libraries look like they're used for GUIs. Do you know if they can be used for the terminal?

DWRITE is very extensible so you can always implement an IDWriteTextRenderer and do all the magic staff in it.

Link: https://docs.microsoft.com/en-us/windows/desktop/directwrite...

Rich text editors' complexity is far beyond ordinary programmer's imagination, especially when complex script (like Arabic) is in it.

It is really good to see they have RTL support.

-- However they messed up when using composing IMEs :(

You have to know that the MSFT may not have the source code of Equation Editor, since it is a simplified version of MathType.

Yes, what is the problems with Windows PC?

The website works well in Edge but you claimed that it does not support that. I have to override the user agent in order to access your editor.

The reason is we did not test carefully on Edge, may have some problems we don't know!

You say you have dependent types

OK, could you define this?

    data Eq : {a : Type} -> a -> a -> Type where
        Refl : Eq x x

    sym : {x : a} -> {y : a} -> Eq x y -> Eq y x
    sym Refl = Refl

    replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y
    replace Refl p = p

So where is the famous Idris elaborator? Where are the universes? Where’s inductive types? Where are they?

Wait, isn’t using TypeScript politically incorrect? It is made by MS!!