[vim/vim] Inconsistency between `[count]` and `v:count` within InsertCharPre autocmd group (Issue #11636)

Seokyong Jung

unread,

Nov 28, 2022, 11:01:40 AM11/28/22

to vim/vim, Subscribed

Steps to reproduce

I made the following autocmd to show popup menu for omni-completion whenever starting to type symbol.

autocmd InsertCharPre *
\  if !pumvisible() && match(v:char, '[[:alpha:].]') != -1 && v:count == 0
\ |   call feedkeys("\<C-X>\<C-O>", "n")
\ | endif

The autocmd itself works fine but it conflicts with repeat operation in Normal mode.

Work as expected: motion r, R

Press {motion}
Type words something
Return to Normal mode
Press . to repeat replacing
The repeat process is done because v:count is equal to 1

Do not work as expected: motion S, s, C, c

Press {motion}
Type something
Return to Normal mode
Press . to repeat replacing
The repeat process followed by feedkeys() call is done because v:count is equal to 0
1. To escape this, from 4, press 1. to repeat replacing

Expected behaviour

From intro.txt:

[count]: If no number is given, a count of one is used.

From eval.txt:

v:count: The count given for the last Normal mode command. Can be used to get the count before a mapping.

During repeat process, v:count becomes zero for some commands.
v:count should be set to one for all above commands even if [count] is not specified intentionally.

Expected behaviour: motion S, s, C, c

Press {motion}
Type words something
Return to Normal mode
Press . to repeat replacing
The repeat process is done because v:count is equal to 1

Version of Vim

8.2 (Extra patches: 8.2.3402, 8.2.3403, 8.2.3409, 8.2.3428)

Environment

Windows WSL (Debian GNU/Linux 11 (bullseye))
xterm-256color
bash

I can reproduce this symptom too on my Mac machine with vim version 9.0.0950.

Logs and stack traces

No response

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Nov 28, 2022, 4:54:32 PM11/28/22

to vim/vim, Subscribed

You mention "because v:count is equal to 1". Where is it specified that this would be so?
I would say there is no count given before the dot, thus v:count should be zero.

You'll have to find a workaround, changing this behavior is likely to cause problems for existing plugins.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Seokyong Jung

unread,

Nov 28, 2022, 5:53:15 PM11/28/22

to vim/vim, Subscribed

You mention "because v:count is equal to 1". Where is it specified that this would be so?

It is indirectly specified in intro.txt and eval.txt where I quoted.
That is what I confused.

Is this inconsistency intended?
If you delete v:count == 0 from above reproduce process, command r, R as well as i, I do not work as intended.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Christian Brabandt

unread,

Nov 29, 2022, 7:34:30 AM11/29/22

to vim/vim, Subscribed

Are you possibly looking for v:count1

					*v:count* *count-variable*
v:count		The count given for the last Normal mode command.  Can be used
		to get the count before a mapping.  Read-only.  Example: >
	:map _x :<C-U>echo "the count is " .. v:count<CR>
<		Note: The <C-U> is required to remove the line range that you
		get when typing ':' after a count.
		When there are two counts, as in "3d2w", they are multiplied,
		just like what happens in the command, "d6w" for the example.
		Also used for evaluating the 'formatexpr' option.
		"count" also works, for backwards compatibility, unless
		|scriptversion| is 3 or higher.

					*v:count1* *count1-variable*
v:count1	Just like "v:count", but defaults to one when no count is
		used.

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Seokyong Jung

unread,

Nov 29, 2022, 7:57:29 AM11/29/22

to vim/vim, Subscribed

Are you possibly looking for v:count1

Thanks for your advice but unfortunately, no.
Its value is always set to 1 when entering Insert mode without specifying [count].
The variable does not fit my case.

What I want to do is satisfying condition for insert mode (and replace mode) during insert mode but not during executing repeat command which enters insert mode.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Seokyong Jung

unread,

Nov 29, 2022, 9:17:19 AM11/29/22

to vim/vim, Subscribed

Anyway, near solution I found is mapping . with multiplying its count 1.

noremap . @='1.'<CR>

This mapping always resets [count] to 1 whenever running . command but it works as I expected.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Seokyong Jung

unread,

Dec 26, 2022, 12:19:06 AM12/26/22

to vim/vim, Subscribed

I noticed that [count] for . is regarded as specified one originally (not the default value 1).

From POSIX:

Repeated commands with associated motion commands shall repeat the motion command as well; however, any specified count shall replace the count(s) that were originally specified to the repeated command or its associated motion command.

So setting v:count as 0 is reasonable than 1 whenever [count] is not specified.