topic: text editor

[lukewilliamboswell]

I would like to work on the test editor chapter. I have a package for handling ANSI escape sequences which are supported in most modern terminals, and is most useful when working with the basic-cli platform.

Here is an illustration of an app using this package, and the code for the tui-menu example.

I think I can expand this example to include opening, editing, and saving files. The main limitation I can think of is limiting this to ASCII and not supporting full unicode.

[gvwilson]

👍 to a simple text editor - I found with the Python version that mapping various coordinate systems to each other and handling basic keyboard input was one chapter, while adding undo/redo was another. Don't know if it would be the same here?

[lukewilliamboswell]

Got something minimal to share and seeking some direction - opening a file from arguments, rendering the text contents to a window.

I've included a super simple implementation of a Piece table which looks to be the easiest way to build a text editor.

I've also used the text segmentation from roc-lang/unicode to split the input file into graphemes so in theory this should support unicode out of the box 🤞

So far the demo only renders text, the editing and saving functionality hasn't been included yet.

I'm pretty sure the undo/redo will be essentially free. The plan is to just keep a new copy of the Piece Table (sans buffers) on each significant user action (edits) in a list. This is just duplicating the indexes into the buffers and so shouldn't grow too significantly unless the user has very long editing session. We can always just keep the latest N edits or something if it becomes a problem.

WIP code for this demo (I haven't removed any of the code from the menu example, just added the parts for editor)

Questions

1. Do you think it is acceptable to render newlines just using "¶", this dramatically simplifies the code code. Though if we want to include line numbers then we will need to handle CLRF breaks anyway?
2. Do we want multiple "pages", like a menu or something, or keep it simple an just open straight into the editing window?
3. Do we want multiple "modes", like vim, command and insert and support different controls in each? This should be pretty easy to support, maybe just a couple of the basics.

Demo

[gvwilson]

This is a great start - well done! I based the editor in the Python book on the first few parts of Wasim Lorgat's tutorial https://wasimlorgat.com/posts/editor.html - I think we definitely want the line breaks, but modes and windows and what-not won't fit into the one-hour limit.

[lukewilliamboswell]

Quick update on progress this weekend.

WIP code branch

• handle line breaks
• remove unused code from previous example
• implement a ViewPort to draw the content (was helpful for testing edge cases, may be useful in future for e.g. editing multiple files)
• enable saving of changes using Ctrl-S keypress
• add text insertion (and implementation for the PieceTable data structure)

I've had to make a few changes to the roc-ansi package, so this has been good to flush those issues out and resolve them.

I've also been adding a lot of inline comments and thinking about the dot points for the chapter content.

Demo

[gvwilson]

this is great work - thank you very much. I think you may already have an hour's worth of teachable material - if you'd like to grab some time with me ([email protected]) I'd be happy to talk you through next steps.

[lukewilliamboswell]

Sounds good. I sent you a meeting request via email. Just took a guess at a suitable time re timezones. Apologies if it's too short notice, I could find a time next week.

I'd like to implement text deletion to close out the Piece table basics. Also I'll need to make a release for the unicode and ansi dependencies before this will be usable more generally.

If you don't mind I'd love to write something up about this for my blog and share in the online meetup this weekend, it won't be the same content as the book more my experience.

[gvwilson]

Blogging about this would be great, and no worries about overlap with whatever you're going to write for the book: you own the rights to your blog posts, so you can decide to recycle them.