Discussion: will reedline become a full-fledged "text editor?"

[Jasha10]

This issue is to discuss direction and scope of reedline's "text editor" and "IDE" features.

The goal of PR #670 was "allowing the user to press "jk" (without modifiers) to move from Vi insert mode to Vi normal mode." In that PR, @benvansleen said:

Achieving this with the existing keybindings section would require implementing something akin to emacs key-chords (since you press one key, release, then press the next). That would be a much, much wider-reaching change.

This seems related to the question of "how many full-fledged text editor features should be added to reedline?" Heavy-duty text editors like vim essentially allow the user to configure a state machine where a given keypress will have a different effect depending on the current state. (For example, the keypress 'k' would have a different effect depending on if the user is in "insert" mode or "normal" mode, and also depending on whether the 'k' immediately followed a 'j'.)

Does it make sense for reedline to move in the above direction (implementing a user-configurable state machine)? Related are questions regarding how many other "text editor" features should be included (e.g. vim allows for user-configurable callbacks, plugins, keymaps to trigger system calls or perform arbitrary turing-complete logic, etc).

I think it could be helpful to discuss vision for how far reedline will move in the direction of becoming a "text editor" / "IDE." Having a vision for this will help to ensure that:

• new features are added in a manner that's consistent with overall vision for user experience, and
• the implementation decisions made in adding new features will not be counterproductive to progress on other planned features.

Related:

• Brainstorming Features #63

[fdncred]

We've wanted to have better VI keybinding functionality for a long time. You can see some of our brainstorming ideas #69, which is linked from the meta issue that you mention above.

I think reedline should cover as much functionality as is supportable. An example of what I mean by that is I like the idea of a user configurable state machine like you mention above. However, if there's no one to write it and no one to maintain it, then it's probably not something reedline should have.

I think this is the problem with many open-source projects. There are a lot of plans and ideas but unless someone comes along to implement and support some feature, it goes undone. Since we're all volunteers, we just work on things that interest us. There is a bug in reedline that has been there for years and prevents WezTerm from working properly. My solution to that was to move to Ghostty because I couldn't figure out the solution.

So, it's probably less a matter of what we want, although that's a good starting place, and more of a matter of who will write it and support it for the community.

[HartBlanc]

Has outsourcing the modal editing logic to a third-party dependency been considered as an option?
e.g. https://github.com/ulyssa/modalkit

I would expect this to address the open issues regarding the limitations of the edit modes and reduce the associated maintenance burden.

[fdncred]

Has outsourcing the modal editing logic to a third-party dependency been considered as an option? e.g. https://github.com/ulyssa/modalkit

I would expect this to address the open issues regarding the limitations of the edit modes and reduce the associated maintenance burden.

Never heard of it, but we're probably open to it.