When I wrote a patch for this a few years ago (which I never ended up finishing/submitting) I used the , register, which is basically the same as your other PR (#19342) but with a different register name that avoids the conflict.

I also added the ; register for the previous redo command. I added that so it's easy to "undo" the last redo with something like:

nnoremap <silent> g. :let [@,, @;] = [@;, '']<CR>

I find that's about 99% of what I want this for: "I want to repeat this change 6 times but oh, after the 2nd I find that I want to make one other tiny change, and now my . is messed up".

Personally I kind of liked that approach. I'm okay with functions too. Just some ideas.

@arp242

Thanks for sharing your approach! The , and ; register idea is elegant and concise.

I considered a register-based approach in #19342, but ultimately chose functions for several reasons:

1. Predictability and Clarity

Registers have implicit behavior that can be surprising:

" What does this do?
let @, = "dd"

" Is it:
" - Delete line?
" - Set repeat to delete line?
" - Something else?

Functions are more explicit:

call setrepeat({'cmd': 'dd'})  " Clear intent: set repeat command

2. Extensibility

Registers are string-based, limiting future enhancements:

" How do we add count, visual mode, or register info?
let @, = "dd"  " Just a string

" vs

" Phase 1 (current)
call setrepeat({'cmd': 'dd'})

" Phase 2 (future) - no breaking changes
call setrepeat({
\   'cmd': 'dd',
\   'count': 3,
\   'register': 'a',
\   'type': 'normal'
\ })

3. Complex Commands

String representation has limitations:

• <Plug> mappings
• Multi-byte characters
• Commands with special characters
• Escaping issues

Dictionary structure handles these naturally.

History feature

I really like your ; register idea for "undo last repeat change"! We could add similar functionality:

" Future enhancement
call setrepeat(getrepeat(-1))  " Restore previous repeat

" Or a history function
let history = getrepeathistory()
call setrepeat(history[1])

This could be added in Phase 2 without breaking existing code.

Main Use Cases

The primary use cases that drove this design:

• Save/restore ("telescope"): let saved = getrepeat() → call setrepeat(saved)
• Plugin integration: call setrepeat({'cmd': ':call MyPlugin()'})
• Future: "vim-repeat" replacement with <Plug> support

For your use case ("undo accidental repeat change"), would a history function work?

" Hypothetical Phase 2 feature
nnoremap <silent> g. :call setrepeat(getrepeat(-1))<CR>

I'm open to feedback, but I believe the function approach provides better long-term maintainability and clarity.

I feel that the specifications are still not well-regulated.

Bug

$ vim --clean +"call setrepeat(#{cmd:'i', text:'Hello'})" +"call feedkeys('.', 't')"

Hello is typed, but Vim remains in insert mode, which is different from the existing . convention and confuses users.

About the document.

Write according to the rules.

:h help-writing
/^STYLE

Especially the following:

Use two spaces between the final dot of a sentence of the first letter of the
next sentence.

The return value must be listed at the end of the function description.

Return type: |Number|

API name

The function names (setrepeat(), getrepeat()) is too abstract. Give it a better name.
Exsample:

dotrepeat_get()
dotrepeat_set()
dotrepeat_clear()

customdot_~()

So getrepeat cannot be used to get the current dot-repeat register, i.e. the last "action" that a user performed (without setrepeat)?

Currently, no. The implementation has two modes:

1. After setrepeat(): Full support ✅

• getrepeat() returns the exact {'cmd': '...', 'text': '...'} that was set
• . command correctly repeats the operation

2. After user operations (like iHello<Esc>): Limited/no support ❌

• getrepeat() returns empty or incomplete information
• The main challenge is extracting the command type (i, a, o, etc.) from Vim's internal state

Why this limitation?

Vim stores repeat information in several places:

• last_insert buffer: contains the inserted text but not the command type
• . register: contains the text but not the command
• redo_buffer: contains the full command but is opaque (can't easily read from Vimscript)

Parsing these internal structures reliably is complex and error-prone.

The main use case still works:

Plugins can save/restore repeat state around temporary operations:

" Plugin performs user operation
execute "normal! iHello\<Esc>"

" Plugin saves its own repeat state
let saved = getrepeat()

" Plugin does temporary work
call setrepeat({'cmd': 'dd'})
normal! .

" Restore original repeat
call setrepeat(saved)

" User's . command still works
normal! .  " repeats the plugin's 'iHello'

Future enhancement:

We could add user operation support by:

• Tracking the last insert command type in a new global variable
• Hooking into insert mode entry/exit to capture this information

Would you like me to implement this, or is the current behavior acceptable for the initial version?

Would you like me to implement this, or is the current behavior acceptable for the initial version?

Not a blocker imo, if we agree the door is open for getrepeat() in the future to get "user operations". Could perhaps be opt-in via a flag.

I have implemented simple user commands support.

@justinmk @zeertzjq What do you think?

@h-east

Thank you for the detailed feedback! I've addressed all the issues:

Bug fix: Fixed the insert mode issue. The problem was that ESC wasn't being appended to the redo buffer for insert mode commands. Now insert commands (i, a, o, etc.) properly exit to normal mode after repeat.

Documentation style: Updated to follow :help help-writing guidelines with two spaces between sentences and return type at the end.

Function naming: I believe getrepeat() and setrepeat() are appropriate for this feature, following Vim's existing patterns like getpos()/setpos(). Could you explain the use case for dotrepeat_clear()? Currently, setrepeat({}) can clear the repeat state, so I'm not sure when a separate clear function would be needed. If there are other related functions you think should be added, I'd be interested to hear about the requirements.

The latest changes are now pushed. Please let me know what you think.

Function naming: I believe getrepeat() and setrepeat() are appropriate for this feature, following Vim's existing patterns like getpos()/setpos().

There's no persuasive power in listing APIs that were implemented early on.
Vim 8 and later actively use API names that follow the format function name prefix + _ + verb, etc.. There's no reason not to follow that.

assert_~(), autocmd_~(), balloon_~(), base64_~(), ch_~(), digraph_~(), job_~(),
js_~(), json_~(), listener_~(), popup_~(), prompt_~(), prop_~(), reg_~(),
sign_~(), sound_~(), test_~(), timer_~(), uri_~(), win_~()

Also, repeat is too "abstract".
Shouldn't you at least add dot?

Could you explain the use case for dotrepeat_clear()?

The specifications haven't been finalized yet, and it was just mentioned as an example, so there's no need to go into too much detail. It might even be a catalyst for something...

Regardless of the API name, I would not accept the current specification.

Thank you for the feedback! I agree that following the Vim 8+ naming convention makes sense.

I'll rename the functions to dot_set() and dot_get() to follow the prefix_verb pattern and make it clear they operate on the dot command.

Regarding your comment "I would not accept the current specification" - could you clarify what concerns you have? Is it:

• The function naming?
• The API design (dict structure, return values)?
• The behavior (how it interacts with user operations)?
• Something else?

I want to make sure I address all the issues before proceeding.

I agree that following the Vim 8+ naming convention makes sense.

I'll rename the functions to dot_set() and dot_get()

Since when is it a vim convention to name functions by the punctuation name ("dot" in this case)? If "repeat" isn't wanted for some reason (why?) perhaps "redo" works.

Also, repeat is too "abstract".
Shouldn't you at least add dot?

I assume this was suggesting dotrepeat, not dot.

But I don't get why we want to avoid "abstraction" to such an extreme; this feature may gain more capabilities in the future.

Thank you for the feedback on naming!

I initially considered repeat_set() / repeat_get(), but avoided it because repeat() already exists and I was concerned about potential confusion.

I chose dot_ because the "dot command" seems to be the most commonly used term among users (rather than internal implementation terms like "redo").

I think that dotrepeat_set() / dotrepeat_get() would be too verbose.

However, you raise a good point about Vim's official terminology. Looking at :help ., "repeat" is indeed the documented term. If the concern about repeat() confusion isn't significant (since they're used in different contexts), I'm happy to go with repeat_set() / repeat_get().

What do you think would be clearest for users?

If we're bikeshedding names, then my 2c is lastchange_get() and lastchange_set(), or something along those lines. In my mind at least that's what . holds: "the last change".

Just an idea; I'm okay with both repeat_get() or dot_get(), or even dotrepeat_get() as well.

@arp242 Thanks for the suggestion!

After thinking about this more, I believe repeat_set() / repeat_get() is the right choice:

1. Official Vim terminology: :help repeat.txt documents this feature as "repeat"
2. Community understanding: The popular vim-repeat plugin has established "repeat" as the intuitive term for this functionality
3. User expectations: When users think about the . command, they think "repeat"

Regarding potential confusion with the existing repeat() function: I think the risk is low because they're used in completely different contexts:

• repeat(string, count) - string manipulation
• repeat_set(dict) / repeat_get() - editor behavior control

The different argument types and use cases make them clearly distinct, similar to how getpos() and pos() coexist without confusion.

What do you think?

I did pipe this through claude and he is not too happy about this:

Review

This is a substantial new feature. Overall thoughts:

Design concerns

The fundamental approach of storing repeat state in a dictionary with
"cmd" and "text" fields is fragile. Vim's repeat mechanism is much
richer than this — it stores a full redo buffer sequence including counts,
registers, operator+motion combinations, special keys, etc. Reducing it to
just cmd+text means:

• setrepeat({'cmd': '3dd'}) — does the count work? Unclear.
• Operator+motion (dw, ci", etc.) — how are these handled? The code
  only explicitly handles iaoOIAcsSC as insert commands.
• setrepeat({'cmd': 'cw', 'text': 'newword'}) — this is documented as
  working but cw is not in the insert command list, so
  set_last_insert_str() would treat it as a non-insert command and just
  replay cw without the text.

The skipRestoreRedobuff mechanism is worrying

Hooking into saveRedobuff/restoreRedobuff with a counter and a skip
flag is fragile — these are called in many contexts and adding bypass logic
could cause subtle redo corruption in edge cases.

g_last_repeat_dict lifetime

g_last_repeat_dict = dict_copy(dict, TRUE, FALSE, get_copyID());
if (g_last_repeat_dict != NULL)
    ++g_last_repeat_dict->dv_refcount;

dict_copy typically sets dv_refcount = 1, so incrementing again to 2
means it would never be freed by normal GC — only by clear_repeat_dict().
That's intentional but worth a comment.

f_getrepeat refcount issue

dict_T *dict = get_repeat_dict();
if (dict != NULL)
{
    rettv->v_type = VAR_DICT;
    rettv->vval.v_dict = dict;
    ++dict->dv_refcount;
}

get_repeat_dict() already sets dv_refcount = 1 for the new dict, then
this increments to 2. The rettv should own the only reference — this looks
like a leak.

clear_repeat_dict() called in nv_operator()

This means any operator command clears the programmatic repeat, which seems
overly aggressive. Moving the cursor with w before . shouldn't clear
it, but any operator will.

Documentation

The docs are verbose and list many limitations upfront, which makes the
feature feel half-baked. The "Limitations" section in setrepeat() with 5
numbered caveats is a red flag — if there are this many limitations, the
API design may need rethinking before exposing it publicly.

Prior art

The existing repeat.vim plugin (by tpope) already solves this problem for
plugins using feedkeys() + a mapping approach. It would be worth
considering whether this feature is sufficiently more capable to justify the
added complexity.

Tests

Good coverage of the happy path, but no tests for error cases (missing
cmd key, wrong types, etc.) and no tests for the tricky interactions with
counts/registers.

This feels like it needs more design iteration before merging.

The existing repeat.vim plugin (by tpope) already solves this problem for
plugins using feedkeys() + a mapping approach. It would be worth
considering whether this feature is sufficiently more capable to justify the
added complexity.

Thank you for the feedback. A brief clarification.

First, why hasn't anyone added this to core before? Simply put, safely handling the redo buffer / the . internal representation is hard. There are multiple complexities:

• . encodes more than a key sequence: counts, registers, operator+motion, special keys (and their escaping), ESC handling, multibyte text, etc.
• The redo buffer is saved/restored at many points in the code, so save/restore nesting and interactions with other logic must be handled carefully.
• Mistakes in internal state management (e.g. refcount handling) can cause leaks or destructive side effects — and indeed some refcount issues have already been flagged in this PR.

Because of these difficulties, leaving the problem alone is understandable. That said, I believe adding this feature to core is worthwhile for several reasons.

Why this is valuable

• Limits of plugin dependencies: repeat.vim and similar feedkeys()-based solutions are useful, but they rely on input emulation and per-plugin adoption. Expecting every plugin author to adopt and correctly integrate an external plugin is not realistic.
• Improved stability and compatibility: a built-in API lets all plugins use a consistent, safe mechanism to handle repeat state, reducing duplication and incompatibilities across the ecosystem.
• Testability: exposing repeat state explicitly makes unit and regression testing easier, which increases long-term reliability.
• Extensibility: we can start with a minimal dictionary (cmd/text) and later extend it (count/register/type) in a backwards-compatible way.

Enabling Vim script to directly read and set redo/repeat state is, in my view, a net benefit. It reduces reliance on fragile input emulation, improves reproducibility and testability, and provides a stable foundation that plugins can build on. For safety, we must proceed incrementally: fix critical bugs first, then harden the save/restore and operator interactions with tests and careful design.

something similar to the "0-"9 registers but for the . redo buffer

It needs to be an event, or perhaps a callback. Otherwise plugins would need to "poll" these registers.

I had to read this a few times to understand what you mean, but I think what you mean is that after setrepeat() is called, there is no autocmd event(?)

So we also need to add a new RedoChanged autocmd, which gets fired not only on TextChanged, but also when setrepeat() is called.

I understand your frustration, but I hope you can be understanding of @chrisbra's use of AI. He is responsible for reviewing and making calls on every single issue and PR. While other members do help, we are severely understaffed. Using AI to streamline this overwhelming workload is a practical necessity and, frankly, makes perfect sense to keep the project moving.

very curious, how did large popular open source projects survive with the overwhelming contributions, pull requests and issues raised before the existence of LLMs? 🧐

I don't know, perhaps being on the edge of becoming burnt out while trying to keep the project alive in their spare time and having barely enough time for their own family, while at the same time aggregating issues and pull requests and trying to manage the community, project goals and security incidents and still trying to be friendly, motivated and open to a random strangers on the internet and managing the communities expectations?

For what it's worth, your friendliness to everyone here (above all else you do) is exemplary, and more than I would have been able to manage. Your efforts are very much seen and appreciated.

I think the conversation about Vim project management/AI somewhere is best done somewhere else. Maybe open a new issue, discussion, mailing list thread, or something. It's not really on-topic here.

That said, maybe we can change some things to be less less Christian-centric? Also see the discussion on how to do patch releases from a few days ago. Again: probably best discussed somewhere else.

But also: I don't think anyone needs to justify themselves to random internet strangers who never contributed to Vim or Vim-adjacent projects (as near as I can tell) and came here from a Mastodon thread to express their outrage. If I were to go around bollocking every project run in a way I dislike then I'd have a full-time job.

The docs are verbose and list many limitations upfront, which makes the
feature feel half-baked. The "Limitations" section in setrepeat() with 5
numbered caveats is a red flag — if there are this many limitations, the
API design may need rethinking before exposing it publicly.

Thank you for the careful review and for pointing out that the current implementation has many limitations.

• I agree that the cmd/text form is intentionally minimal and does not capture the full richness of Vim's redo buffer.
• The current choice was pragmatic: fully reproducing the redo buffer (counts, registers, operator+motion, mappings, etc.) is complex and risky to implement in one pass.
• To address this:
  1. Documented the supported cases and clearly listed the current limitations.
  2. Added tests covering the supported behaviors.
  3. "raw redo-buffer" feature can be added later(planned).

I don't know, perhaps being on the edge of becoming burnt out while trying to keep the project alive in their spare time and having barely enough time for their own family, while at the same time aggregating issues and pull requests and trying to manage the community, project goals and security incidents and still trying to be friendly, motivated and open to a random strangers on the internet and managing the communities expectations?

If you're at the edge of a burnout, more and faster paced work is not going to help you. Take rest, work however much you feel comfortable with. We will be here, and we will appreciate carefully laid out and slowly paced development all the same. Don't feel pressured to "keep up" with whatever speed is advertised by snake oil sellers. Take care.

I have been thinking about this for a bit more and I am wondering if we shouldn't approach it slightly differently, since this approach here is a bit fragile. First we would need to refactor the existing redo byte stream buffer into a bit more structured representation for those redo commands (command, count, motion, insertedtext, key, register, etc). That would make getrepeat()/setrepeat() straightforward to implement cleanly on top, and would benefit other areas that currently have to parse or reconstruct redo buffer contents. The raw byte stream would however likely needed for macros or mappings.
But note, that this would likely be a larger refactor, but it might save complexity in the long run.

What do you think?

I agree — treating the redo buffer as a raw byte stream is fragile.

But note, that this would likely be a larger refactor, but it might save complexity in the long run.

My approach also requires multiple pull requests to implement the feature correctly.
I think refactoring first is preferable.

Thank you for the detailed feedback! I’ve addressed all the issues:
Thank you for the feedback! I agree that following the Vim 8+ naming convention makes sense.
Thank you for the feedback on naming!
Thanks for the suggestion! After thinking about this more, I believe repeat_set() / repeat_get() is the right choice:
Thank you for the feedback. A brief clarification.

Wow, this real person must be really thankfull

Wow, this real person must be really thankfull

Lol, Thank you for all your feedback.

closing for now