Vim composer mode: support inner-word text objects (`ciw`, `diw`, `yiw`)

Resolved 💬 6 comments Opened May 6, 2026 by lucidash Closed May 27, 2026

What variant of Codex are you using?

CLI / TUI

What feature would you like to see?

Now that Vim composer mode has landed, it would be useful to support common inner-word text objects in the composer:

  • diw: delete inner word
  • ciw: change inner word and enter insert mode
  • yiw: yank inner word

These are common Vim muscle-memory commands and fill a small gap in the existing composer Vim mode rather than adding a new mode.

Additional information

The existing Vim composer mode supports normal/insert mode and d/y operator flows. Inner-word text objects make those flows feel much closer to expected Vim behavior for prompt editing.

I have a small focused patch with tests that adds these commands in codex-rs/tui/src/bottom_pane/textarea.rs. If this is something maintainers would be open to, I would be happy to open a PR.

Related:

  • Follow-up to #18595
  • Related to #9184
  • Similar behavior was discussed in #3044

View original on GitHub ↗

6 Comments

lucidash · 2 months ago
Mahkhmood9 · 2 months ago

this is a issue is actually a great example of how great community driven projects are

sorry for my bad english once again

Pretty much your offer is pending chars

without over complexing thing, like how does vim does it
but vim does right.. its seems like reciepie for a lot of issues

like having keys sync , if keys act in the same specification as vim itself -- if anything can glitch?

If you are typing diw, normal.c hits a line of code where it literally says: "I have a 'd', now I need a motion. Hey getchar.c, give me the next thing?
speaking of there is a need for a more mature behavior? (as per your commit https://github.com/openai/codex/compare/main...lucidash:codex:fix/vim-inner-word)

https://github.com/vim/vim/blob/master/src/normal.c#L182C3-L198C1
https://github.com/vim/vim/blob/master/src/getchar.c
https://github.com/vim/vim/blob/master/src/getchar.c

lucidash · 2 months ago

@Mahkhmood9

Thanks, I think I understand your point. To be honest, this started as a quick
patch because I wanted to use ciw/diw/yiw myself right away, so I kept it
deliberately small instead of trying to model Vim's full getchar/typeahead
machinery.

I agree that if this grows beyond a few common text objects, a more general
operator-pending / pending-key state machine would be the cleaner direction.
For this patch, I was mainly trying to fill the immediate gap with tests and
check whether maintainers are open to the behavior.

Mahkhmood9 · 2 months ago
@Mahkhmood9 Thanks, I think I understand your point. To be honest, this started as a quick patch because I wanted to use ciw/diw/yiw myself right away, so I kept it deliberately small instead of trying to model Vim's full getchar/typeahead machinery. I agree that if this grows beyond a few common text objects, a more general operator-pending / pending-key state machine would be the cleaner direction. For this patch, I was mainly trying to fill the immediate gap with tests and check whether maintainers are open to the behavior.

I just fear it been something that going to cause issue, text insertion is very sensetive , and there is also the TUI aspect , which seems complex.... its very sensetive all of those keystores

I tried your commit it seems to be solid 👍

Mahkhmood9 · 2 months ago

Unrelated by I want to refrence https://github.com/openai/codex/issues/21562

For example VIM is one of those software that works anywhere (yes including a native built for windows, and cmd and powershell) and vim for example is very harden for TUI or whatever

again I actually praise Codex CLI for how stable it is , considering the alternatives (in terms of TUI)