Feature: optional vim-style modal editing in the compose entry

[sypianski]

Summary

Per CONTRIBUTING ("suggest your change in an issue first"), I'd like to gauge whether an optional vim-style modal editing mode for the message compose entry fits the project scope before proposing it for merge.

Motivation

Users with vim muscle memory (and keyboard layouts that reserve Alt for diacritics, making the default Alt-based entry shortcuts unusable) would benefit from modal editing in the compose box.

Proposal

A single ui.conf option vim_mode (default 0 → no behavioral change, zero overhead). When enabled:

• Modes: insert / normal / visual; entry starts in insert, Esc → normal.
• Composable operator + motion engine (not hardcoded combos):
  • Motions: h l 0 ^ $, w e b W E B, ( ) sentence, { } paragraph, j k, gg G, f F t T.
  • Operators d c y × any motion; dd cc yy; D C.
  • Edit: x X, s S, o O, p P; counts (3w, d3w, 2dd).
  • Visual mode with reverse-video selection highlight.
• Feedback: status-bar mode badge (colors configurable in color.conf) + DECSCUSR cursor shape (bar/block). set_escdelay(25) to keep ESC snappy.

When vim_mode=0, the new key handler early-returns to the existing EntryKeyHandler — no change for existing users.

Implementation

A working implementation is on a branch (touches uimodel, uientryview, uistatusview, uiconfig, uicolorconfig, ui; ~850 lines, formatted with make.sh src/uncrustify, builds clean):

https://github.com/sypianski/nchat/tree/feature/vim-mode

Happy to open a PR if this fits the project scope, or to adjust the surface (e.g. command subset, config naming) per your preference.

Known limitations (v1)

• Visual mode has no named registers; single unnamed register only.
• W/E/B currently alias w/e/b (no separate WORD class yet).
• Motions index raw wstring positions; wide-emoji (EMOJI_PAD) edge cases not specially handled.
• No . repeat / r replace yet.

[d99kris]

Hi @sypianski - thanks for proposing a concrete vim-style keyboard input mode and providing an implementation.

Vim-style key bindings is the most requested feature not yet implemented - see #241 - so I think there is some good reason to consider adding this.

I'll just need to familiarize myself a little more with vim and review the suggested bindings and get back here, hopefully in a not too distant future.

[octvs]

Hey there @sypianski, just gave you branch a try. On my initial testing it works very well w/ my muscle memory.

Regarding #241, I think there are two requests packed into one there:

• Navigating the UI via vim style key bindings
• Writing a message via vim mode

I think this addresses the latter, whereas the discussion was started for the former. Although some comments diverted interest to the latter case on the thread.

Tackling former might be possible somewhat via key.conf, but I have not yet given it a try.

[d99kris]

Hey there @sypianski, just gave you branch a try. On my initial testing it works very well w/ my muscle memory.

Regarding #241, I think there are two requests packed into one there:

• Navigating the UI via vim style key bindings

Thanks for the feedback!

I think we may consider doing this vim style key bindings in two phases, first the compose edit (this patch) and later app navigation.

[sypianski]

Hey, I would go not only with phases, but with separate modules. For instance, I am personally very happy with the current navigation (tab, ^N) and would prefer not to have the vim navigation in nchat tui, but I completely understand people might want it.

[d99kris]

Hey, I would go not only with phases, but with separate modules. For instance, I am personally very happy with the current navigation (tab, ^N) and would prefer not to have the vim navigation in nchat tui, but I completely understand people might want it.

Good point - it might make sense to treat them as two separate options.