Rewrite MultiLineTextEditView (FSE Backing)

[NuSkooler]

I've learned a lot plus a lot has changed in the surrounding system since the initial version of the MultiLineTextEdit view -- the backing for FSE/etc. TextEditView and MaskEditView currently do not allow arrow key movement nor pipe codes either, and could benefit from sharing code or even sub classing MLTEV.

A rewrite is in order. This is a meta task for discussion & tracking of related issues.

Open Issues:

• Pipe code support in message reader #126
• Crash in MultiLineTextEditView when using pipe codes #147
• Overtype mode in MultiLineEditTextView is broken #10
• EditTextView should allow movement keys #6

New Design Goals:

• "Live" pipe codes
• Edit within ANSI buffers (e.g. in quoted ANSI)
• Use ES6 classes
• Additional editor controls
  • Word prev & next movement
  • Word prev & next delete
• Backspace past start of line handling (bring row up)
• Delete at end of line handling (bring next row up)
• Single line mode
  • Enter submits
  • Tab switches field
  • Max length, no word wrap, etc.
• Overtype mode functional

Bonus Goals:

• Bonus: specialization for full width view
  • Use scroll regions if available
• Basic markdown support
  • Highlight text surrounded by tick (`) marks, asterisks (*), etc.
• VTX hyperlink support

Some initial design thoughts:

• For pipe color codes: As the user types in a pipe code, once one is complete (e.g. |04) it should disappear and switch the text color attribute. If the user backspaces, it should reappear as an incomplete code (|0).
• The system should maintain the text being edited and per-character/cell attributes. The editing position vs visual render position must also be tracked for cursor movement.
• Cells should also contain ANSI vs Pipe attributes such that we can export appropriately. Imported ANSI should remain ANSI. Quoted ANSI should at a minimum export as ANSI like it currently does.

[davestephens]

This all looks and sounds awesome!

One thing that immediately comes to mind is live spell checking - maybe not pertinent to all uses of the MLTEV, but being able to toggle it on/off per case would be awesome (ie for the FSE!). There are a few decent dictionary packages already out there, so should be a case of just connecting the dots...

Picture I have in my head is that if it detects an incorrect word then it'd be highlighted live, then before the view is submitted something could be done with the incorrect spellings, ie a GUI to fix them or ignore etc. First cut could just be highlighting them, the GUI stuff could obvs come later.

[robbiew]

Was just about to leave a feature request for pipe-code support in messages! These look like awesome design goals.