I don't understand.

q"<C-V>32<Esc>kqqqp<C-A>S<C-R>"q94@q

Breakdown:

q" -> begin recording into unnamed register
<C-V> -> enter visual block mode?
32 -> give count for next command
<Esc> -> cancel next command and leave visual block mode
k -> fails because this is a new buffer and there is only one line
...the rest really doesn't matter at this point

Why did you expect this to do *anything*?

Did it post incorrectly? Are there characters missing?

It works well on linux, I tested vim 7.3.712, on  Mac OSX 10.8.2 the version 
7.3 (2010 aug 15) also works,  but not with the windows vim version (I have 
7.3.831, the last version).
The k fail at start (first line) but it is registered in the macro to run 
after, the next lines.
This is big feature of vim (to have dynamic keystroke).
Thanks a lot, for the comment !

This monstrosity was discoverd by the leaderboard expert vim member (No.1) of 
vimgolf (practical vim) on a challenge to create the list  of ASCII chars, see 
the link : http://vimgolf.com/challenges/50b1517e9aad890002000004

I tested with vim 7.3.822 (I use only console versions) version on win 7, but 
doesn't work . Thanks a lot for the answers .

OK, I think after studying and thinking about the macro, I understand what it's 
doing.

It starts by initializing the unnamed register. The actual q macro which gets 
executed will first paste the unnamed register literally, then increment the 
numeric value (previously in the unnamed register), then replace the line 
content with the contents of the unnamed as if typed (via CTRL-R). Repeating 
this will increment the byte value being inserted as with CTRL-V + number.

So there are a few ways this could fail.

First, I'm not sure, whether i_CTRL-V_digit takes encoding into account or not. 
You could be using a different encoding on Windows, one which does not use the 
same bytes to represent the ASCII characters. What does ":set encoding?" tell 
you? I cannot reproduce when mine is Latin1.

Second, you could have a mapping interfering. The most likely candidate in my 
mind is a potential mapping for CTRL-V in insert mode. Does ":verbose map! 
<C-V>" tell you anything?

Third, you could have another mapping or setting interfering. Do you see the 
problem, when you launch Vim with:

  gvim -N -u NONE -U NONE -i NONE

or

  vim -N -u NONE -i NONE

Even if you have no .vimrc (or _vimrc) on Windows, there is a default installed 
which you should try bypassing.

If none of these fixes the problem, you may have found a real issue, but I have 
no idea what else could cause the difference between our systems now that 
you've tried the same version I'm using.

Hello,

What does ":set encoding?" tell you?
 encoding=latin1

I did =>
1.
 :verbose map! <C-V>
No mapping found

and
2 also :verbose map  and two times  Ctrl-V 
 :verbose map ^V
No mapping found

I don't see anything when launched :  vim -N -u NONE -i NONE

In tested with vim 7.3.822, but I have same problem.
I compiled vim with vc9 (VS2008), with the options, see at the top.
Thanks a lot for studying and thinking about this problem! 

Hello,
  For Vim 7.3.822 win32 the keystrokes line :

 1Gqa<C-V>32<Esc>kqqq"ap0<C-A>"aS<C-R>aq94@q

doesn't work.

Best regards !

What do you mean by, "I don't see anything when launched :  vim -N -u NONE -i 
NONE"?

Does this mean the issue goes away, and the macro works as intended, when you 
launch Vim with those flags?

If this is the case, we have:

1. Not an encoding issue
2. Not an obvious mapping issue
3. Some issue brought to light with your config but not mine

If this is the case, Can you remove stuff from your vim config until you have a 
minimal configuration which demonstrates the issue?

I don't have any vimrc file.
I compiled vim with : nmake -f Make_mvc.mak GETTEXT=no FEATURES=HUGE
and now it works.
Also with FEATURES=BIG and FEATURES=NORMAL
I can't compile for FEATURES [TINY, SMALL], I have a link problem:

        link /RELEASE /nologo /subsystem:console /LTCG:STATUS -out:vim.exe .\ObjCi386\blowfish.obj  .\ObjCi386\buffer.obj  .\ObjCi386\charset.obj  .\ObjCi386
\diff.obj  .\ObjCi386\digraph.obj  .\ObjCi386\edit.obj  .\ObjCi386\eval.obj  
.\ObjCi386\ex_cmds.obj  .\ObjCi386\ex_cmds2.obj  .\ObjCi386\ex_docmd.obj  .\ObjC
i386\ex_eval.obj  .\ObjCi386\ex_getln.obj  .\ObjCi386\fileio.obj  
.\ObjCi386\fold.obj  .\ObjCi386\getchar.obj  .\ObjCi386\hardcopy.obj  
.\ObjCi386\hashtab.ob
j  .\ObjCi386\main.obj  .\ObjCi386\mark.obj  .\ObjCi386\mbyte.obj  
.\ObjCi386\memfile.obj  .\ObjCi386\memline.obj  .\ObjCi386\menu.obj  
.\ObjCi386\message.ob
j  .\ObjCi386\misc1.obj  .\ObjCi386\misc2.obj  .\ObjCi386\move.obj  
.\ObjCi386\normal.obj  .\ObjCi386\ops.obj  .\ObjCi386\option.obj  
.\ObjCi386\os_mswin.obj
  .\ObjCi386\winclip.obj  .\ObjCi386\os_win32.obj  .\ObjCi386\pathdef.obj  .\ObjCi386\popupmnu.obj  .\ObjCi386\quickfix.obj  .\ObjCi386\regexp.obj  .\ObjCi38
6\screen.obj  .\ObjCi386\search.obj  .\ObjCi386\sha256.obj  
.\ObjCi386\spell.obj  .\ObjCi386\syntax.obj  .\ObjCi386\tag.obj  
.\ObjCi386\term.obj  .\ObjCi386\
ui.obj  .\ObjCi386\undo.obj  .\ObjCi386\window.obj  .\ObjCi386\vim.res          
   .\ObjCi386/if_cscope.obj    .\ObjCi386\version.obj oldnames.lib kernel32.l
ib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib ole32.lib uuid.lib 
/machine:i386 /nodefaultlib  libcmt.lib   user32.lib             /PDB:vim.pdb 
-debug
misc1.obj : error LNK2001: unresolved external symbol _modify_fname
vim.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Microsoft Visual Studio 9.0\VC\BIN\link.EXE"' : 
return code '0x460'
Stop.

Thanks a lot !

The vim version I tested and works is 7.3.842. Also I applied this patch (from 
message 68488 ):
...
While I don't can anything contribute to this specific problem, which
seems to be related to Windows only, I noticed one specific problem.
After recording the key-sequence above, I can't seem to be able to run
that specific command again, i.e. it will always continue with the
latest ascii code and continue increasing it. I suspect, this happens,
because register " and 0 come out of sync and so recording to register "
will always use the value from register 0.

This patch fixes it:

t a/src/ops.c b/src/ops.c
--- a/src/ops.c
+++ b/src/ops.c
@@ -1089,7 +1089,9 @@

retval = stuff_yank(regname, p);

- y_previous = old_y_previous;
+ /* allow changing the default register, if it was specified */
+ if (regname != '"')
+ y_previous = old_y_previous;
y_current = old_y_current;
}
} 

...

> I don't have any vimrc file.

Are you sure? Windows Vim looks in these places for a vimrc file, do ANY of them
exist?

$HOME/_vimrc
$HOME/.vimrc
$VIM/_vimrc
$VIM/vimrc

> I compiled vim with : nmake -f Make_mvc.mak GETTEXT=no FEATURES=HUGE
> and now it works.
> Also with FEATURES=BIG and FEATURES=NORMAL

So...you recompiled and now the issue is not reproduceable, using the same
config (or lackthereof)? Are you retracting your bug report?

You didn't answer, is the issue reproduceable with:

  vim -N -u NONE -i NONE

You said "I don't see anything" but I have no idea what you meant by that. Do
you mean "it did not fix the issue" or "I don't see the issue" or even "Vim did
not launch correctly"?

I verified, I don't have any vimrc:
$HOME/_vimrc
$HOME/.vimrc
$VIM/_vimrc
$VIM/vimrc
At the start of  vim with vim -N -u NONE -i NONE, I see nothing , and after 
starting the issue is reproduceable.
But I find the problem: The issue is reproduce able all time, also with the vim 
7.3.842 when I used numeric keypad (on the right) to input 32 value.
When I use the numeric keys above the letters, the macros works. 
Thanks a lot for helping !
Best regards !

I finally reproduced the issue, using the keypad like you discovered; so 
although you still didn't explain, it's probably not important at this point 
what you didn't see.

I certainly would not expect this behavior, but I actually think I know the 
cause. I suspect it's because Vim actually distinguishes between 1 and <k1>, 2 
and <k2>, etc. keys to allow mapping them differently. So the macro contains 
special escape sequences for the keypad keys which aren't present when using 
normal numerics.

To demonstrate the difference, try the following:

qao<k1><k2><k3><Esc>q
qbo123<Esc>q

Both these macros do the same thing when executed. Both will make a new line 
with text, 123. But now examine the register contents:

:reg a
:reg b

For me at least, on Windows gvim, they are drastically different!

Not all systems actually send Vim a different sequence for the keypad keys; on 
these systems, 1 and <k1> are not separately mappable.

I think this will only pop up when somebody tries using a recorded macro both 
as a recording and as text for insertion and manipulation. I'm not sure whether 
it's possible to fix without breaking the separate mapping capability of the 
keypad, or even if there is something to fix at all.

A person who wrote the macro in the first place would know what they were 
trying to accomplish at each step in the macro. When they pasted the contents 
of the unnamed register, hoping to get a numeric value which could then be 
incremented, if they saw the special escape sequences, they would immediately 
know something was wrong. I don't actually think there is anything to fix here, 
unless it's just seen as another place Vim's internal representation of special 
keys causes weird behavior.

I got lost. Is this a valid bug report or not?

In note #12 the problem was identified as something to do with the numeric 
keypad.
Thus the issue is solved.

The macro is used in this challenge :  ( tested now with vim 7.4.453 works ! )
http://vimgolf.com/challenges/50b1517e9aad890002000004

The last challenge "Winding path", Urtica Dioica created, is amazing (It's a 
Maze):

http://vimgolf.com/challenges/543e53c037ba3a00022b3ec7
Best regards !