The German vimtutor currently contains a spelling error I fixed in the attached 
patch.

If both, completeopt=menu,preview and cursorcolumn are set, the completion menu 
will vanish upon the first completion choice that would bring up the preview 
window. The preview window still works and is browseable, the menu still is 
gone, though.

The bug has bitten other people too:
https://github.com/Rip-Rip/clang_complete/issues/6
http://leetless.de/vimrc.txt

To reproduce, follow this (will assume installed python completion support):
1) Open a new python file with vim
1) a) vim foo.py
2) Set completion
2) a) filetype plugin on
2) b) set omnifunc=pythoncomplete#Complete
2) c) set completeopt=menuone,menu,longest,preview
3) Set cursorcolumn
3) a) set cursorcolumn
4) Import some stdlib that has docstrings

import string
foo = ""
foo.

5) Press <C-X><C-O>
6) Choose from list
7) Menu will vanish

The last rev I tested this on was 177 and there don't seem to be any relevant 
changes since then.

Hopefully that's helpful. 

What steps will reproduce the problem?

1. $ echo "for i in range(1,4) | %s/r/x/gc | endfor" > temp.vim
2. $ vim -N -u NONE -U NONE temp.vim
3. :so % 
4. Note that issuing a Ctrl-C interrupts the loop
5. :map <c-c> abc
6. :unmap <c-c>
7. :so %
8. Issuing Ctrl-C do NOT interrupted the loop anymore.

What is the expected output? What do you see instead?
It was expected that the behavior of Ctrl-C before mapping and after mapping 
and unmapping would be the same, breaking the loop.

What version of the product are you using? On what operating system?
Vim 7.3 under Windows XP.

Please provide any additional information below.
As an attempt to workaround the problem it was tried to ':unmap <c-c>' and then 
':map <c-c> <c-break>', using Ctrl-Break as described in ':help :map_CTRL-C', 
but it didn't worked, in despite that directly typing Ctrl-Break breaks the 
loop.

Reference information: 
http://stackoverflow.com/questions/7485740/capturing-break-interrupt-command

Following the suggestion by Bram Moolenaar while discussing 7.3.363 I'm opening 
an issue to serve as a reminder to myself that I promised I would have a look 
at it.

#v+
char foo[]
#ifdef FOO_BAR
= { a, b, c, d, /* FIXME: this line should be indented more because it is a
                 * continuation line. */
    e, f, g, h,
    i, j, k, l }
#endif
    ;
#v-

In a static enum the second and following enums will be indented too much:
#v+
static enum {
    FOO,
        BAR,
        BAZ
} foo;
#v-

What steps will reproduce the problem?
1. Press <ESC> (Very important, not only for leaving any mode)
2. Press <SHIFT> + O
The time between 1. and 2. needs to be short enough.

What is the expected output? What do you see instead?
If, instead of pressing <SHIFT> + O, we press just O, the response is very 
quick as expected. Weirdly, with <SHIFT> + O the response is very slow to come. 
Sometimes, it even print a 'O' and then change its mind end do what's expected 
(i.e. open a line before the current one in INSERT mode)

What version of the product are you using? On what operating system?
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 24 2011 07:10:07)

In a gVim for windows, when there are more than one windows in a gVim, even 
more, if there are two or more vertical window in a gVim, scroll the wheel only 
scroll the windows at last one in this row, not the one under cursor or the one 
has input cursor.

reproduce:

1. gvim -u NONE -U NONE
2. :h<CR>
3. :vert sp<CR>
4. move input cursor to first window, and move mouse on the first window, 
scroll the wheel, the text in second window scrolls.

regards,

Xavier Wang.

au BufNewFile,BufRead hg-editor-*.txt setf hgcommit

And a search found this syntax file:
http://code.delroth.net/configs/src/ca2adbde207b/.vim/syntax/hgcommit.vim

What steps will reproduce the problem?

1. Run Gnome 2 desktop environment.

2. In Gnome, System menu -> Preferences -> Assistive Technologies, pops up a 
window, click "Mouse Accessibility" button, pops up a window, click "General" 
tab, enable "Show position of pointer when the Control key is pressed".

3. In .vimrc, map C-C to something (e.g. use mswin.vim to map C-C to copy)

4. Run gvim

5. Press C-C (e.g if in mswin mode, select some text (e.g. Shift-DownArrow a 
couple of times then press Ctrl-C)

What is the expected output?

Selected text is copied. Selected text stays highlighted.

What do you see instead?

No text is copied (C-V won't paste it). Selected text gets unhighlighted; 
visual mode is exited.

What version of the product are you using? On what operating system?

64-bit Ubuntu Natty, Ubuntu-packaged gvim (vim 7.3.35). Also happens with 
7.3.219 built from latest Hg source.

Please provide any additional information below.

This can be fixed (or perhaps just hacked around) by editing gui_gtk_x11.c near 
the end of function key_press_event() from:

    if (len == 1 && ((string[0] == Ctrl_C && ctrl_c_interrupts)
           || (string[0] == intr_char && intr_char != Ctrl_C)))
    {
    trash_input_buf();
    got_int = TRUE;
    }

to:

    if (len == 1 && ((string[0] == Ctrl_C && ctrl_c_interrupts && !mapped_ctrl_c)
           || (string[0] == intr_char && intr_char != Ctrl_C)))
    {
    trash_input_buf();
    got_int = TRUE;
    }

But a better solution probably relies on correctly setting ctrl_c_interrupts to 
WAR the issue described below.

Background:

If the Gnome option "show mouse pointer position" is not set, ctrl_c_interrupts 
is false when the C-C keypress is received, and everything works.

However, due to the extra keypress events processed when "show mouse pointer 
position" is enabled, ctrl_c_interrupts gets set back to true, and C-C triggers 
trash_input_buf() etc. The extra keypress events from the Control key being 
pressed are injected from focus lost/gained events, which IIRC get injected 
from gui.c function gui_focus_change().

What steps will reproduce the problem?
1. Bring up vim with syntax off
2. Position the cursor at the open paren of a line like (hash-table-set! 
the-table "SETUP,create,original" ");")
3.

What is the expected output? What do you see instead?
Expect it to match the close paren at the end of the line. Instead, it matches 
the close paren inside the string.

What version of the product are you using? On what operating system?
7.3.289. Slackware Linux 13.37 64-bit

Please provide any additional information below.

In Vim code there is a file called farsi.h which includes code which can be 
simplified to:

char_u foo[]
#ifdef BAR
= { 0, 1
    2, 3 }
#endif
;

char_u baz[]
#ifdef
= { 4, 5,
    6, 7 }
#endif
;

Automatic code indentation in Vim causes everything following the first 
"#endif" to be indented one level too many.

In the following examples the arguments declarations and the function return 
types respectively are not indented while they should be:

#v+
/* comment */
    int
foo(a,
    b)
int a;
int b;
{
    return 0;
}

int
bar(
    int a,
    int b)
{
    return 0;
}
#v-

What steps will reproduce the problem?
1. In a `vim -u NONE` do

    try | foldopen | catch | echom v:exception

What is the expected output? What do you see instead?
Expected: `Vim(foldopen):E490:...` message or such

Got:

    Error detected while processing :
    E490: No fold found

What version of the product are you using? On what operating system?

vim-7.3.382 from mercurial repository, Gentoo amd64

:help format-comments mentions that it is possible to specify an offset for the 
end of a three-piece comment:

  {digits}
    When together with 's' or 'e': add {digit} amount of offset to an
    automatically inserted middle or end comment leader. The offset begins
    from a left alignment. See below for more details.

  -{digits}
    Like {digits} but reduce the indent.  This only works when there is
    some indent for the start or end part that can be removed.




This seems to have never been implemented. If you are interested in 
implementing the feature, I made a small first step: I modified insertchar() in 
edit.c so that the closing part is correctly indented (with the offset) when 
the auto-close comment functionality is triggered but:
• my solution uses spaces – it does not take into account the value of
  'et', 'ts', etc.,
• get_c_indent() does not handle the offset setting.

If you decide to implement this, at least the settings mentioned above will 
have to be considered (perhaps other as well).

You might have a look at the attached patch (against Vim 7.3.189) if you'd like 
a pointer to where to start. Also have a look at open_line().

The upcoming C standard supports new keywords. The following patch adds them to 
the syntax highlighting. Also, it adds some missing C99 keywords (_Bool, 
_Complex, _Imaginary and imaginary).

With 'cino' set to "(0,l1,Ws" the following C code gets indented incorrectly:
- foo2a(void) is indented too much,
- foo2b(void) is indented too much but by a different amount.

This happens for me in Vim 7.3.189.

/* some comment */
        int
foo1(void)
{
        bar();
}

/* some comment
 * ): */
        int
        foo2a(void)
{
        bar();
}

/* some comment
 * ):
 * and even some more. */
        int
          foo2b(void)
{
        bar();
}
/* some comment
 * : */
        int
foo3a(void)
{
        bar();
}

/* some comment
 * :
 * and even some more. */
        int
foo3b(void)
{
        bar();
}

What steps will reproduce the problem?
1. Enable syntax highlighting, set the filetype to CSS (open a CSS file).
2. Type in the following (note no space between the brace and the :hover):
a:hover{
  color:black;
}

What is the expected output? What do you see instead?
See before and after screenshots. CSS properties are not syntax highlighted and 
the '}' brace is highlighted as having a no-matching-bracket error.

What version of the product are you using? On what operating system?
Hg tip has the problem.

Please provide any additional information below.
The problem is the regex used to match pseudo-classes (PS) also matches the '{' 
character if there's no space between the PS and the '{'.

The attached patch corrects the regex to only match alphabet characters and 
hyphens.

What steps will reproduce the problem?
1.
    ./configure --prefix=/usr --localstatedir=/var/lib/vim \
        --mandir=/usr/share/man \
        --with-features=huge --enable-gpm --enable-acl --with-x=no \
        --disable-gui --enable-multibyte --enable-cscope \
        --disable-netbeans --enable-perlinterp=dynamic \
        --enable-pythoninterp=dynamic --enable-python3interp=dynamic \
        --enable-rubyinterp=dynamic --enable-luainterp=dynamic

2. make

What is the expected output? What do you see instead?
success build


What version of the product are you using? On what operating system?
7.3.410, archlinux

Please provide any additional information below.

build ends with:

objects/if_ruby.o: In function `window_s_aref':
if_ruby.c:(.text+0x31f): undefined reference to `rb_fix2int'
if_ruby.c:(.text+0x361): undefined reference to `rb_num2int'
objects/if_ruby.o: In function `buffer_s_aref':
if_ruby.c:(.text+0x3cf): undefined reference to `rb_fix2int'
if_ruby.c:(.text+0x419): undefined reference to `rb_num2int'
objects/if_ruby.o: In function `window_set_width':
if_ruby.c:(.text+0x105d): undefined reference to `rb_num2int'
if_ruby.c:(.text+0x1089): undefined reference to `rb_fix2int'
objects/if_ruby.o: In function `window_set_height':
if_ruby.c:(.text+0x10cd): undefined reference to `rb_num2int'
if_ruby.c:(.text+0x10f9): undefined reference to `rb_fix2int'
objects/if_ruby.o: In function `window_set_cursor':
if_ruby.c:(.text+0x1170): undefined reference to `rb_num2uint'
collect2: ld returned 1 exit status
link.sh: Linking failed
make[1]: *** [vim] Error 1
make[1]: Leaving directory `/build/src/vim-build/src'
make: *** [first] Error 2

What steps will reproduce the problem?
1.input these codes:
    if (!c) {
        // 当字符为 # 时 ...
        if (c=='#') {
            // 当字符为 { 时 ...
        } else if(c=='{') {
            // 当字符为其他
        }
    }
2. "=gg"
3. the result:
    if (!c) {
        // 当字符为 # 时 ...
        if (c=='#') {
            // 当字符为 { 时 ...
        } else if(c=='{') {
            // 当字符为其他
        }
        }

What is the expected output? What do you see instead?
expected:
    if (!c) {
        // 当字符为 # 时 ...
        if (c=='#') {
            // 当字符为 { 时 ...
        } else if(c=='{') {
            // 当字符为其他
        }
    }
instead:
    if (!c) {
        // 当字符为 # 时 ...
        if (c=='#') {
            // 当字符为 { 时 ...
        } else if(c=='{') {
            // 当字符为其他
        }
        }

What version of the product are you using? On what operating system?
Ver: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Oct 6 2011 10:20:05)
OS : xubuntu 11.10

Please provide any additional information below.
it's a bug of c code indent.

Try indenting a file with the following contents:
#v+
// vim: cindent et

void func(void)
{
        int a[] =
        {
                1, 2,
                3, 4};
        printf("This is indented too much!\n");
}
#v-

Currently Vim indents printf too much:
#v+
// vim: cindent et

void func(void)
{
        int a[] =
        {
                1, 2,
                3, 4};
                printf("This is indented too much!\n");
}
#v-

I am attaching a patch which fixes the problem. The patch also contains a test 
for the situation described above. While trying to fix the problem at one point 
I caused Vim to behave incorrectly while indenting a switch block. The 
incorrect behaviour was not detected by the test suite so I am also adding a 
test for switch.

Spelling correction (denier -> dernier)

This patch updates the syntax highlighting for the D programming language to 
reflect recent additions to the standard version identifier list. In addition, 
it adds some core types to the highlighting (optionally enabled with 
d_hl_object_types).

Open any markdown file, vim will complain about error in ftplugin 
file, line 17

This line contains following:

let b:undo_ftplugin .= "|setl cms< com< fo<"

It's assumed that the variable already exists whereas it's not true and other 
ftplugins just define this variable.

What steps will reproduce the problem?
1. open a file with vim
2. in a new terminal, open the same file with another vim instance
3. resize your terminal

What is the expected output? What do you see instead?
I expect the text to reformat while the terminal resizes. Instead, the text 
gets garbled and never formats properly again. In some cases, the output 
remains affected after dismissing the prompt, during editing. In either case, 
the problem can sometimes be fixed by resizing the terminal window once again 
while editing.

What version of the product are you using? On what operating system?

$;vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Nov 16 2010 17:05:25)
Included patches: 1-56
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent 
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs 
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path 
+find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv 
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent 
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape 
+mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse 
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype 
+path_extra +perl +persistent_undo +postscript +printer +profile +python 
-python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent 
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
 -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
 -xterm_clipboard -xterm_save 
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim73"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall  
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  -D_FORTIFY_SOURCE=1     
Linking: gcc   -L.  -rdynamic -Wl,-export-dynamic  -Wl,--enable-new-dtags 
-Wl,-rpath,/usr/lib64/perl5/CORE   -L/usr/local/lib -Wl,--as-needed -o vim      
 -lm -lnsl  -lselinux  -lncurses -lacl -lattr -lgpm -ldl    
-Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE  -fstack-protector  
-L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread 
-lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm 
-Xlinker -export-dynamic   -lruby -lpthread -lrt -ldl -lcrypt -lm   


Fedora 14, XFCE window manager, and xfce4-terminal


Please provide any additional information below.

What steps will reproduce the problem?
1. Open a LaTeX document that uses IEEEeqnarray
2. Enter this string: \begin{IEEEeqnarray}{rCl}x_0 & = & x_1\end{IEEEeqnarray}
3. Notice that the underscores are highlighted as errors

What is the expected output? What do you see instead?
The underscores are highlighted as errors.  Everything within IEEEeqnarray 
should be treated as mathmode syntax

What version of the product are you using? On what operating system?
7.3 on Gentoo and Ubuntu 11.04

Please provide any additional information below.

I believe this can be trivially demonstrated by doing:

    :autocmd CursorHoldI * silent execute 'call feedkeys("\<C-r>\<Esc>", "n")'

hitting "i", and watching memory usage instantly skyrocket.  Various other 
permutations also trigger the leak though.  The speed of the leak will 
obviously vary with 'updatetime'; for the most immediate effect, set it to a 
very low value.  Oddly, feedkeys() in a CursorHold autocommand (i.e. in normal 
mode, not insert mode) does not leak.

Among other plugins, Conque <https://code.google.com/p/conque/> does this.  
It's a hack, obviously, but until Vim gets real support for some kind of async 
events, it's one of the more portable techniques; notably, it works without 
+clientserver so it can be used in vim in a PTY rather than a GUI.

I am not including a bugreport.txt because this seems to affect all versions of 
Vim 7.3 that I tried it with, so it does not seem runtime or plugin dependent.

Thanks for your consideration, and thanks for Vim,

-glyph

**What steps will reproduce the problem?
1. vim with -A some_arabic_file
2. type arabic characters { appears properly } 
3. then type some english characters {in the same file}, the english one 
appeaers in reverse order . { screanshot : http://ompldr.org/vYTJqZw } 

**What is the expected output? What do you see instead?
the English  characters apeares properly , but they appeaers in reverse order . 
What version of the product are you using? On what operating system?
on Linux Fedora 14 64
*my :version  { 

:version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Nov 16 2010 17:05:25)
Included patches: 1-56
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent 
-clientserver -clipboard +cmdline_compl
+cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind 
+cursorshape +dialog_con +diff +digraphs -dnd
-ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path 
+find_in_path +float +folding -footer +fork()
+gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap 
+libcall +linebreak +lispindent +listcmds +localmap
-lua +menu +mksession +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm 
-mouse_jsbterm +mouse_netterm -mouse_sysmouse
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype 
+path_extra +perl +persistent_undo +postscript
+printer +profile +python -python3 +quickfix +reltime +rightleft +ruby 
+scrollbind +signs +smartindent -sniff +startuptime
+statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white 
-tcl +terminfo +termresponse +textobjects
+title -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra 
+viminfo +vreplace +wildignore +wildmenu
+windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard -xterm_save
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim73"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall  
-fexceptions -fstack-protector --param=ssp-buffer-siz
e=4 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  
-D_FORTIFY_SOURCE=1
Linking: gcc   -L.  -rdynamic -Wl,-export-dynamic  -Wl,--enable-new-dtags 
-Wl,-rpath,/usr/lib64/perl5/CORE   -L/usr/local/lib
 -Wl,--as-needed -o vim       -lm -lnsl  -lselinux  -lncurses -lacl -lattr -lgpm -ldl    -Wl,--enable-new-dtags -Wl,-rpath,/u
sr/lib64/perl5/CORE  -fstack-protector  -L/usr/lib64/perl5/CORE -lperl -lresolv 
-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -
L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker 
-export-dynamic   -lruby -lpthread -lrt -ldl -lcr
ypt -lm
}
Please provide any additional information below.

the issue accrue  on all terminal-emualters :konsole , terminator and 
gnome-terminal . 

What steps will reproduce the problem?

1. install Vim on Windows 7
2. start gVim
3. insert text in the buffer

What is the expected output? What do you see instead?

The unexpected output is the message:
E303: Unable to open swap file for "[No name]", recovery impossible

What version of the product are you using? On what operating system?

Vim 7.3.46, self identifying as:
Vim 7.3 (2010 Aug 15, compiled oct 27 2010 17:59:02)
MS-Windows 32-bit GUI version with OLE support
Included patches: 1-46
Compiled by Bram@KIBAALE

Please provide any additional information below.

gVim uses the default setting for the "directory" option, that is, it gets 
".,c:\\tmp,c:\\temp", which originates from os_dos.h.

Unfortunately, none of these were writable on a vanilla Windows 7 install. cwd 
is C:\Windows\system32, and neither c:\tmp nor c:\temp exist.

This differs from the behavior of the identical installer package on Windows 
XP. cwd on Windows XP seems to originate from the HOME environment variable, 
which is writable.

A good solution would cause installs on Windows 7 to have cwd be from HOME on 
startup, just as on Windows XP.

Changing the "Compatibility Mode" for Vim under Windows 7 to "Windows XP 
(Service Pack 3)" does not correct cwd, so it is not a useful workaround. The 
same is true of changing "Start In" on the gVim shortcut from empty to %HOME%.

Adding a "set directory" to .vimrc and appending a writable directory is a good 
temporary workaround. Both of these worked:

set directory+=$HOME
set directory+=$TEMP

"In chapter 4 several ways to make small changes were explained." - missing 
comma after "4". Patch attached.

What steps will reproduce the problem?
1.$ gvim -U NONE -u NONE somefile.c (somefile.c should exist and contain some 
lines);
2.use 'j' to move cursor down;
3.If it cannot reproduce, repeat 1-2.

What is the expected output? What do you see instead?
The cursor should move quickly, but the cursor takes seconds to move. So do 
following cursor movements.

What version of the product are you using? On what operating system?

It's on linux.

VIM - Vi IMproved 7.3 (2010 Aug 15, compiled May 20 2011 20:24:03)
Included patches: 1-198
Compiled by xuhong@xuhong-PC
Huge version with GTK2 GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent 
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff 
+digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi 
+file_in_path +find_in_path +float +folding -footer +fork() +gettext 
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall 
+linebreak 
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse 
+mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse 
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg +path_extra -perl 
+persistent_undo +postscript +printer +profile +python/dyn +python3/dyn 
+quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff 
+startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static 
-tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar 
+user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace 
+wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact 
+xterm_clipboard -xterm_save 
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: icc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12     -O3      
Linking: icc   -L/usr/local/lib -Wl,--as-needed -o vim   -pthread -lgtk-x11-2.0 
-lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 
-lgdk_pixbuf-2.0 -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig 
-lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0   -lSM -lICE -lXpm 
-lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl  -lselinux   -lacl -lattr -lgpm 





I see many deprecated gtk codes in the vim source. Maybe it's caused by them?

What steps will reproduce the problem?
1. Put the jq.js file in a temporary directory (say in ~/tmp/jq/jq.js).
2. cd to ~/tmp/jq/ .
3. Invoke gvim.
3. Type «:grep -r URI .»
4. Type :cn

What is the expected output? What do you see instead?

gvim tries to edit a new file with an unmanagable name instead of keep editing 
the very long line of jq.js. 

What version of the product are you using? On what operating system?

gvim-7.3.237 on Mageia Linux Cauldron x86-32.

Please provide any additional information below.

It also happens on Mandriva Linux Cooker on x86-64 with gvim-7.3.2xx mhi^ from 
IRC verified it to happen to.

What steps will reproduce the problem?
1. In your .vimrc file add the following:
   set lines=40
   let temp=system('ls')
2. Start either gvim or vim -g

What is the expected output? What do you see instead?
Vim should be started with its gui and with 40 lines. Instead, the number of 
lines will be reset to the number of lines of the terminal from which Vim was 
started.

What version of the product are you using? On what operating system?
$> vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Aug 25 2011 12:51:53)
Included patches: 1-285
Compiled by lervag@lervag-laptop
Huge version with GTK2 GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent 
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff 
+digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi 
+file_in_path +find_in_path +float +folding -footer +fork() +gettext 
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall 
+linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname 
+mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm 
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg 
+path_extra -perl +persistent_undo +postscript +printer +profile +python 
-python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent 
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
 +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim 
+xsmp_interact +xterm_clipboard -xterm_save 
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12     -g -O2 -D_FORTIFY_SOURCE=1      
Linking: gcc   -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-dynamic  
-L/usr/local/lib -Wl,--as-needed -o vim   -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lm 
-lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 
-lgthread-2.0 -lrt -lglib-2.0   -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE 
-lm -lncurses -lnsl  -lselinux  -lacl -lattr -lgpm     
-L/usr/lib/python2.6/config -lpython2.6 -lpthread -ldl -lutil -lm -Xlinker 
-export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions   -lruby1.8 -lpthread -lrt 
-ldl -lcrypt -lm  -L/usr/lib   

Please provide any additional information below.
I have supplied a simply vimrc-file which can be used to test the error with 
the same setup that I have used. I know that I can set &lines in gvimrc, but I 
like to keep all my settings in one file.

In the following code sample the second comment is indented incorrectly:

#v+
    void
func(void)
{
    int abc; /* comment
              * NOTE: this is indented correctly. */
    int def; /* comment
NOTE: this is not indented correctly.
This is due to the colon following NOTE. */
}
#v-

This is just a test that issues reported at  
http://code.google.com/p/vim/issues are forwarded to the vim_dev maillist.

What steps will reproduce the problem?

1. open a file in vim
2. set rnu
3. open a second file using :vs (it must be a second file, opening a second 
view of the same file with ":vs" by itself maintains the rnu setting)

What is the expected output? What do you see instead?

I expect to see relative line numbering in the new window, but instead see the 
default line numbering.

What version of the product are you using? On what operating system?

cloned 7.3 as of today, on OS X Snow Leopard.

What steps will reproduce the problem?
Try indenting a file with the following contents with the settings as specified 
by the modeline:

#v+
// vim: cindent cino=(0,gs,hs et sw=8
class Foo : public Bar
{
        public:
                virtual void method1(void) = 0; // FIXME: 2 indent levels
                virtual void method2(int arg1,
                                     int arg2,
                                     int arg3) = 0;
};
#v-


What is the expected output? What do you see instead?

The output file should be identical as the input but instead method 
declarations are indented one level too few:

#v+
// vim: cindent cino=(0,gs,hs et sw=8
class Foo : public Bar
{
        public:
        virtual void method1(void) = 0; // FIXME: 2 indent levels
        virtual void method2(int arg1,
                             int arg2,
                             int arg3) = 0;
};

#v-

As noted in the summary, the problem was introduced in 7.3.202.

What steps will reproduce the problem?
1. reboot
2. right click any file
3. after menu popup, LANG environment variable (with value zh_CN) is injected 
to explorer.exe (which will affect any new child process of it)

What is the expected output? What do you see instead?
-

What version of the product are you using? On what operating system?
vim73_46 on Windows XP Professional (Simplified Chinese).

Please provide any additional information below.
I'm not sure why VIM need a LANG environment variable to be put to 
explorer.exe, because even without LANG environment, vim display the correct 
GUI language (for me, it's simplified chinese).

Add a LANG environment variable to explorer.exe will affect all new child 
process, I often use Cygwin 1.7, LANG will affect Cygwin to display 
Chinese/multibytes characters.

If LANG environment is needed by vim.exe/gvim.exe, why not putenv to 
vim.exe/gvim.exe itself instead of explorer.exe?

related code may be here:
http://code.google.com/p/vim/source/browse/src/GvimExt/gvimext.cpp#286

What steps will reproduce the problem?
1. browse to http://vimdoc.sourceforge.net/htmldoc/help.html
2. click the link "index.txt" under *reference_toc*

What is the expected output? What do you see instead?

Expect to see the alphabetical index of all commands node. Instead, get the 
help node.


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. vim -u NONE -c 'call range(1, 947948399)'

What is the expected output? What do you see instead?
Just E342 error. Instead got «Vim: Caught deadly signal ABRT» with this error.

What version of the product are you using? On what operating system?
vim-7.3.322 (gentoo ~amd64), vim-7.3.346 (mercurial repository, huge features, 
no GUI and CFLAGS=" -O0 -ggdb3 "), x86_64-pc-linux-gnu-gcc version 4.4.5.

What steps will reproduce the problem?
1. Edit a .h file that is for Objective-C++ (that is, it has C++ classes and 
Obj-C classes both).

What is the expected output? What do you see instead?
":set ft?" should show "objcpp", but instead shows "objc".

What version of the product are you using? On what operating system?
Vim 7.3 (MacVim) on Mac OS X 10.7, but this is true on all systems because of 
runtime/filetype.vim.

Please provide any additional information below.

A patch to fix this by reusing g:c_syntax_for_h is attached.

Example reproduction steps:
1. Open several files in one copy of vim; for example: vim *.c
2. While the first copy is running, open the same files in another copy of vim; 
in another terminal window, for example.
3. Hit "o" at each swap file prompt, and the spacebar at each "-- More --" 
prompt.

The "-- More --" prompt currently shows up far too often, about every three 
files on a large screen.  I expect the swap file prompt to count as having 
allowed me to see the lines on the screen.

This occurs on every copy of vim I've tried; in particular, it happens in 
Ubuntu 10.10's pre-packaged 7.2 (2:7.2.330-1ubuntu4), both gui and console, and 
in hand-built console versions from the Mercurial repository: vim72 branch 
(v7-2-446) and default branch (v7-3-230).

The attached patch attempts to fix the issue for all console prompts, by 
resetting lines_left in msg_end_prompt().  This has been verified to fix the 
swap file prompt for both Mercurial heads, but has not been tested for other 
types of console prompts, nor for gui prompts.

In the following example the indentation incorrectly is constantly growing:

#v-
static foo_t foo[] =
{
    {
        "a"
    }, {
        "b"
    }, {
        "c"
    },
        {
            "d" // FIXME: this is indented too much
        }, {
            "e"
        },
            {
                "f"
            }, {
                "g"
            },
                {
                    "h"
                }
};
#v-

In the following examples the calls to c() and d() are indented too much:

#v+
void func()
{
    if (a)
        b();
    else
        foo:
            c();
    d();

    if (a)
        b();
    else
        bar:
        {
            c();
            d();
        }
    e();
}
#v-

Consider the following script:

    vim -u NONE -c 'set clipboard=exclude:pattern' \
                -c 'set clipboard+=autoselect'

You will see that 'clipboard' option is now containing 
`exclude:pattern,autoselect`, while it should contain 
`autoselect,exclude:pattern` as `exclude:` interprets rest of the options as 
its argument.

this bit of code in configure.in:
  AC_MSG_CHECKING([uint32_t is 32 bits])
  AC_TRY_RUN([...........],
  AC_MSG_RESULT(ok),
  AC_MSG_ERROR([WRONG!  uint32_t not defined correctly.]),
  AC_MSG_ERROR([could not compile program using uint32_t.]))

causes problems when cross-compiling in that it always fails.  the fix is to 
change that last AC_MSG_ERROR() into an AC_MSG_WARN().  if you read the 
autoconf spec, you'll see that the last arg is for cross-compiling, not for 
when the compile fails.

a simple patch by Maksim Melnikau has been posted here:
https://bugs.gentoo.org/attachment.cgi?id=243615

http://www.gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fTRY_005fL
INK_005fFUNC-2135

If --enable-pythoninterp is specified on the command line and Python is not 
found in the path, then Vim will build anyway without the Python interpreter. 
This patch to configure.in makes sure that ./configure fails without continuing.

I plan to implement more checks like that in the branch 
'autoconf-error-on-unattainable-features' here:

http://code.google.com/r/shlomif-changes/

Regards,

-- Shlomi Fish

In the following example some lines are indented too little:

#v+
void func()
{
    switch (foo)
    {
        case (bar):
            if (baz())
            quux(); // FIXME: this line should be indented more!
            break;
        case (shmoo):
            if (!bar)
        { // FIXME: this brace is indented too little
        }
        case (foo1):
            switch (bar)
        { // FIXME: this brace is indented too little
            case baz:
                baz_f();
                break;
        }
            break;
        default:
            baz();
            baz();
            break;
    }
}
#v-

The :nohlsearch command is named somewhat unfortunatelly. Years ago, as a 
newbie, I came to believe that it is a convenience shortcut for :set 
nohlsearch. Instead of using :nohlsearch, I created a mapping using 
'invhlsearch'. Over time, this misconception of mine introduced unpleasant side 
effects, most notably when sourcing files from autocommands.

I believe this is mainly a documentation issue. The attached patches try to 
improve the 'pattern.txt' and 'options.txt' files.

The discussion on vim_dev is here: http://tinyurl.com/cfdz6rl

What steps will reproduce the problem?

1. Add
set nocompatible
set mouse=a
to ~/.vimrc

2. Start vim. Insert some text, hit escape, :! enter to access shell, then 
press enter to return to vim. Now, try to move the cursor by using the mouse to 
click on some character. 

What is the expected output? What do you see instead?

You should be able to move the cursor by clicking with the mouse but noting 
happens.

What version of the product are you using? On what operating system?

It looks like that bug was introduced by the changes done in version 7.3.343 as 
it works fine in 7.3.342. The bug is still present in 7.3.353. The OS is Linux.

Please consider adding a mode to enable and disable abbreviations. Currently, 
one can disable them but only with the command ":abc <buffer>", which deletes 
all the abbreviations and is also difficult to figure out (":abc" by itself 
doesn't work). There is a recent discussion thread on the user's list covering 
this problem. I am thinking along the lines of ":set noabbrev" and ":set 
abbrev".