Vim Macro to generate ASCII characters

[GoogleCodeExporter]

What steps will reproduce the problem?
1.In a new buffer input the keystrokes line (macros) :

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

What is the expected output? 

!
"
#
$
%
&
'
(
)
*
+
,
-
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?
@
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
[
\
]
^
_
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
~
What do you see instead?
<start of buffer>

€KF€KEk
<End of buffer>

What version of the product are you using? On what operating system?
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 21 2013 21:57:55)
MS-Windows 32-bit console version
Included patches: 1-831
Compiled by tst_vimw7@tst_vimw7PC
Huge version without GUI.  Features included (+) or not (-):
+arabic          +ex_extra        -mouseshape      +tag_binary
+autocmd         +extra_search    +multi_byte      +tag_old_static
-balloon_eval    +farsi           +multi_lang      -tag_any_white
-browse          +file_in_path    -mzscheme        -tcl
++builtin_terms  +find_in_path    -netbeans_intg   -tgetent
+byte_offset     +float           +path_extra      -termresponse
+cindent         +folding         -perl            +textobjects
+clientserver    -footer          +persistent_undo +title
+clipboard       +gettext/dyn     -postscript      -toolbar
+cmdline_compl   -hangul_input    +printer         +user_commands
+cmdline_hist    +iconv/dyn       +profile         +vertsplit
+cmdline_info    +insert_expand   +python/dyn      +virtualedit
+comments        +jumplist        -python3         +visual
+conceal         +keymap          +quickfix        +visualextra
+cryptv          +langmap         +reltime         +viminfo
+cscope          +libcall         +rightleft       +vreplace
+cursorbind      +linebreak       -ruby            +wildignore
+cursorshape     +lispindent      +scrollbind      +wildmenu
+dialog_con      +listcmds        +signs           +windows
+diff            +localmap        +smartindent     +writebackup
+digraphs        -lua             -sniff           -xfontset
-dnd             +menu            +startuptime     -xim
-ebcdic          +mksession       +statusline      -xterm_save
+emacs_tags      +modify_fname    -sun_workshop    -xpm_w32
+eval            +mouse           +syntax          
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
Compilation: cl /Od /I "src\proto" /I "\Py27\include" /I "src" /D "WIN32" /D 
"_DEBUG" /D "_CONSOLE" /Gm /EHsc /RTC1 /MTd /FAcs /Fa"Debug" /Fo"Debug\" 
/Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TC /errorReport:prompt -DHAVE_PATHDEF 
-DFEAT_CSCOPE  -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DDEBUG /MTd 
-DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_PYTHON -DDYNAMIC_PYTHON  
-DDYNAMIC_PYTHON_DLL="python27.dll" -DFEAT_HUGE 
Linking: link /OUT:"\vim_20130217\src\vim.exe" /NOLOGO /LIBPATH:"\Python27\lib" 
/MANIFEST:NO /DEBUG /PDB:"\vim_20130217\src\vim.pdb" /MAP /MAPINFO:EXPORTS 
/SUBSYSTEM:CONSOLE /FIXED /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib 
user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib 
ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib oldnames.lib 
/nodefaultlib  /fixed:no libcmtd.lib  user32.lib /nodefaultlib:python27.lib
  DEBUG BUILD

Please provide any additional information below.
1.
In windows vim version when input the keystokes
next to <C-A> after p command I see: €KF€KEk 
I captured these lines with V"*y and paste here.
2.
Linux Vim Version 7.3.712 work well with the command line:
q"<C-V>32<Esc>kqqqp<C-A>S<C-R>"q94@q
(like at the top)

Original issue reported on code.google.com by Go.Zu...@gmail.com on 25 Feb 2013 at 7:21

[GoogleCodeExporter]

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?

Original comment by fritzoph...@gmail.com on 25 Feb 2013 at 8:06

[GoogleCodeExporter]

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 !

Original comment by Go.Zu...@gmail.com on 25 Feb 2013 at 9:27

[GoogleCodeExporter]

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

Original comment by Go.Zu...@gmail.com on 25 Feb 2013 at 10:01

[GoogleCodeExporter]

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 .

Original comment by Go.Zu...@gmail.com on 25 Feb 2013 at 10:58

[GoogleCodeExporter]

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.

Original comment by fritzoph...@gmail.com on 26 Feb 2013 at 2:34

[GoogleCodeExporter]

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! 

Original comment by Go.Zu...@gmail.com on 26 Feb 2013 at 6:55

[GoogleCodeExporter]

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 !

Original comment by Go.Zu...@gmail.com on 26 Feb 2013 at 7:18

[GoogleCodeExporter]

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?

Original comment by fritzoph...@gmail.com on 26 Feb 2013 at 10:07

[GoogleCodeExporter]

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 !

Original comment by Go.Zu...@gmail.com on 27 Feb 2013 at 12:12

[GoogleCodeExporter]

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;
}
} 

...

Original comment by Go.Zu...@gmail.com on 27 Feb 2013 at 12:36

[GoogleCodeExporter]

> 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"?

Original comment by fritzoph...@gmail.com on 27 Feb 2013 at 7:56

[GoogleCodeExporter]

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 !

Original comment by Go.Zu...@gmail.com on 27 Feb 2013 at 11:36

[GoogleCodeExporter]

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.

Original comment by fritzoph...@gmail.com on 28 Feb 2013 at 5:17

[GoogleCodeExporter]

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

Original comment by chrisbr...@googlemail.com on 11 Oct 2014 at 8:09

[GoogleCodeExporter]

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

Original comment by brammool...@gmail.com on 12 Oct 2014 at 10:21

• Changed state: Fixed

[GoogleCodeExporter]

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 !

Original comment by Go.Zu...@gmail.com on 16 Oct 2014 at 10:48