Consumers will a TUI widget that can display typed commands at the bottom of the screen, and a widget that is capable of wrapping WindowLayout and switching between different tabs.

In order to support the Emacs keybinding M-f (and C-Right and M-Right) for #33, I'm going to add a new movement, MoveType::WordAfter, which moves up to the point right the end of a word.

Rather than just track the last message (Screen::set_last_message), I would like Screen to track all historical messages via a Screen::push_message method.

I added ApplicationAction in #9 and parameterized several types on it, but really they should probably be parameterized on a type that implements an Application trait, which then contains an ApplicationAction.

I want to be able to place things in the left and right gutters of lines. I've come up with something that still has some issues, but I'm happy with for a first attempt.

In #33 , I skipped adding support for for accessing the command bar with M-x, and was also unaware of Emacs' C-U keybinding to enter a count argument to an action. I'm going to add both of those now.

In order to implement ^O for #33, I'm going to extend the existing OpenLine action, which is used for implementing Vim's o and O keys. The main difference in behaviour is that in Vim it behaves in a linewise fashion, and in Emacs it behaves in a charwise fashion.

Similarly, I want to extend TypeChar to support inserting a character after the cursor, which could be used to implement a close (but not the same) effect as ^O in Emacs. Everything needed to implement this is already in place, the enum just needs a MoveDir1D argument.

Finally, I'm going to move TypeChar, OpenLine, and Paste out of Action, and into a new InsertTextAction type, in order to help simplify match statements that handle Actions.

The editing module contains a lot of important types and code, but much of it is undocumented. I'm going to add basic documentation for everything and add deny(missing_docs) to the module to make sure that it stays documented.

Consumers need an interface for defining commands (like :q, :w, etc.).

tmux has a feature that allows zooming in on the current window using ^Bz. It would be nice if WindowLayout supported similar functionality.

This will include:

• #26
• #25
• #24
• #23
• #22
• #21
• #20

Properly suspending yourself can be a little tricky, so it'd be nice to provide a method to help people do it rather than reimplement it.

I want a set of base types that can be returned from the keybinding code to describe editing actions to take.

Kakoune's join behaviour always inserts a single space for every line break replaced. I'm going to add a JoinStyle to control EditAction::Join behaviour, instead of the current boolean.

Emacs keybindings would help demonstrate the crate's flexibility, and could also be useful for consumers of the readline module, who want to create CLI tools that allow switching between keybinding styles.

I started adding support for tabs in #18, but I never added the commands for creating new ones. I'm going to add:

• TabAction::Open to support :tabedit/:tabnew
• TabAction::Move to support :tabmove
• TabAction::Extract to support Vim's <C-W>T

There's an Action for completing text, Complete, but nothing to use it with at the moment. It would be nice if there were a way for consumers to provide code for determining completions given a prefix, to provide application-contextual choices (e.g., complete a username or room alias in iamb). There should also be a way to gather words from a buffer and offer those as options.

There are several different styles for display text completion options in Vim: ^N/^P in Insert mode to show and navigate a menu, replacing the word at each step, <Tab>/<S-Tab> in Command mode to replace the word with the options, and ^D in Command mode to show a multi-column list of completions without actually replacing the text with any of them. To avoid pushing figuring out how to render the overlay menu onto consumers, Screen should probably handle displaying completions, at least by default.

In order for the default Vim keybindings to be useful to a variety of applications, Action will need to be extensible with a users own actions. To support this, I'll add a new variant, Action::Application(T), and turn Action into Action<T> so that consumers can create their own action types.

The Vim model of editing shares a lot of information between buffers, and also sometimes has buffer-local values. I'd like some components that can track this kind of information (digraphs, marks, and registers for now) and can be shared between the buffers.

Now that I have the ModalMachine code written, and the types added in #1, I can set up mappings for the Vim keybindingins.

Pretty much everything that's needed for providing a readline-style editor/prompt is already in place. All that's needed is some crossterm calls to take care of rendering the EditBuffer, most of which will look pretty similar to what's already done for the TextBox widget.

Vim's . will repeat the last edit sequence, optionally overriding either the count argument or the register. This is usually a non-motion, non-yank operation, but movements associated with entering Insert mode (i/I/a/A) are included, making it possible to use . to repeat prepending or appending text.

Emacs also supports repeating actions with C-x z, but in its case it is only the very last action, and not a sequence. The count can also be overriden, making it possible to do things like c M-5 C-x z to type the letter c, and then repeating typing it 5 times.

In Kakoune, you can repeat an edit sequence with ., and you can also repeat certain selection commands with <A-.>.

In order to support all of these different styles, I'm going to add support to ModalMachine for tracking different sequences of generated actions by delegating to Mode for determining when and how an action is tracked.

In order to implement M-x SPC and M-\ for #33, there will need to be a way to target adjacent whitespace around the cursor. I'm going to add a RangeType::Whitespace to make this possible.

I would like the repo to have a GitHub action that runs the tests and checks that rustfmt is happy for pushed commits and pull requests.

The current method for determining whether it's okay to access the last column is very Vim-specific. I'm going to add a new method to EditContext which controls whether it is okay to use the last column during an EditAction::Motion.

I'm also going to add another method to allow controlling where the cursor gets placed after editing the buffer. This will allow implementing ~ in a more obvious way that will play nicely with using . to repeat case changes, and will also help in #32 with supporting Kakoune's <A-o>/<A-O>.

In order to support M-c for #33, there will need to be a need Case::Title enum to pass to EditAction::ChangeCase.

I added support for recalling previous entries to ReadLine in #30, but didn't add it to CommandBarState. I'd like to make sure that I have an easy to access example of using the components within the widgets module with the different keybinding environments, so I'm going to add a simple in-memory text editor example. I'm also going to add a MixedBindings type that can wrap the Vim and Emacs keybindings to allow determining which one gets used at runtime.

I want to be able to change what a window looks like when it's focused. This means that WindowLayout will need to pass information to .draw() when rendering to indicate whether or not the window is the currently focused one.

There's currently several Action types for recording macros (MacroExecute, MacroRepeat, MacroRecordToggle), and EditRepeat, but nothing to use them with. I'll need to figure out a way to store recorded macros in the target register, and allow passing the contents along to a ModalMachine instance.

crossterm doesn't have a way to parse a string into a KeyEvent vector, or convert a KeyEvent into it ANSI escape sequence, which would make implementing this easier.

There are a lot of traits, methods, etc., that I didn't document when I first wrote them. A lot of them could do with at least a simple description to help give people a basic idea about what they do.

This should build on top of the generic interface in #16 and take care of defining a default set of commands from Vim.

There's still more to do before this can be easily used by consumer libraries, but I'd like to be able to look at the latest docs on docs.rs, so I'll do an intermediate release.

In order to support building iamb, I would like to have a library that helps building modal editing interfaces. To start with, I need a component that can help map keyboard input to actions to take. It needs to support the following high-level features:

• Multiple modes where input is interpreted differently, so that I can have a Normal mode, an Insert mode, and so on
• Support for prefixing input with counts (1234), registers ("A) and more
• Support for building pseudo-modes like operation-pending mode, so that common suffixes can be created for operations like d and y
• Support for handling unmapped keys so that Insert mode can just type
• Support for fetching the current mode so that the user interface can tell the user what mode they're in

To demonstrate the crate's flexibility, it would be nice to provide the default Kakoune keybindings, which is a different take on modal editing.

There's an action for performing keyword lookups (Action::KeywordLookup), but nothing to help make it functional. Since this is ultimately very application-specific, there probably only needs to be a method to help fetch the word under the cursor's current position.

There's already some basic support for multiple selections to help with managing Vim's counted inserts, and inserting around blockwise selections, but more work is needed for #32 in order to support Kakoune's editing style. To start with, I'm going to add:

• SelectionAction::Duplicate to support duplicating selections onto adjacent lines (Kakoune's C and <A-C>)
• SelectionAction::Trim to support shrinking selections so that they aren't selecting whitespace on their ends (Kakoune's _)
• Enhance SelectionAction::Resize to handle more ways to resize existing selections
• Allow for different ways of splitting existing selections into smaller ones

There are types for moving around the jumplist and changelist (Action::Jump, PositionList::ChangeList, PositionList::JumpList), but nothing to consume them at the moment.

I want a TUI widget that I can use with the tui create that handled do window splits, resizes, and so on.

I'd like a component that holds onto, tracks, and applies edits to the EditRope added in #5. It should be capable of handling the following EditAction variants for now: Delete, Yank, Replace, Join, and Motion. It should also take care of undo/redo actions, and be aware of multiple cursors so that it can handle Vim's I/A/c keys while making blockwise visual selections.

The Vim keybindings "o" and "O" are used to open new lines above or below the current one. Since they move into Insert mode, they need to set InsertStyle::Insert in the context.

There are types for paragraphs and sentences (MoveType::ParagraphBegin, MoveType::SentenceBegin, RangeType::Paragraph, and RangeType::Sentence), but they aren't currently handled in EditRope.

In order to support pressing the Emacs keybinding C-SPC in #33, and the Kakoune keybinding ; in #32, I'm going to add a way to resize existing selections based on resolving an EditTarget at the current cursor position.

I'm also place it and the current Action::SelectionCursorSet and Action::SelectionSplitLines in their own SelectionAction to help reduce the size of match statements that handle Action.

A lot of the Vim editing model revolves around special cursor movements and ranges. I'd like to place this logic in its own trait for a wrapper around a string type. (For now, it will be wrapping xi_rope, although I might eventually change this depending on how well it works out.)

I've been doing HistoryCommand::Checkpoint independently in iamb, but really it should be dictated by the Vim mode transition logic.

Kakoune has movements that Vim and Emacs do not, so I'm going to add the following:

• EditTarget::Boundary to support moving to the start or end of a RangeType (needed for Kakoune's [, ], {, }, and their Alt variants)
• WordStyle::Number to support selecting numbers with n in Kakoune's Object mode
• WordStyle::AlphaNum and WordStyle::NonAlphaNum in order to get closer to Emacs' word movement
• WordStyle::Whitespace to replace RangeType::Whitespace
• MoveType::FinalNonBlank to support Vim's g_

There are two registers, Register::SelectionClipboard and Register::SelectionPrimary, that map onto the operating system's clipboard. On X11 and Wayland, these are two different selections, and need to be fetched in different ways.

I want a TUI widget that I can use with the tui crate that can render EditBuffer instances, and handle scrolling through them.

I've stubbed this out a little, but there's currently no implementation of CursorSearch::find_regex, and nothing to hook up what gets typed at a command bar with Register::LastSearch ("/).