The message cannot be represented in 7-bit ASCII encoding and has been sent as a
binary attachment.

When I set encoding to utf-8 and let $lang zh_CN.UTF-8, the tooltips
can't display correctly and the popup menu on tabpage also. I found
the problem is that the tool tips is utf-8 encoding, it should be
translated to active codepage encoding.

ocean wrote:
> When I set encoding to utf-8 and let $lang zh_CN.UTF-8, the tooltips
> can't display correctly and the popup menu on tabpage also. I found
> the problem is that the tool tips is utf-8 encoding, it should be
> translated to active codepage encoding.
>

I may be wrong, but I think this problem was addressed by a recent bugfix.
Which version and patchlevel are you using? (See the first five lines from the
output of ":version"; and if there is no line starting "Included patches:" it
means you are at patchlevel zero (no patches included).

See at http://ftp.vim.org/pub/vim/patches/7.0/README a one-line summary of
every bugfix published so far for Vim 7.0.

For Windows, you can get an "updated" distribution at
https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721
-- see the "release notes" for the corresponding ":version" listing.

If you want something even more recent, or a different choice of features, you
can compile Vim yourself, see (for Windows)
http://users.skynet.be/antoine.mechelynck/vim/compile.htm


Best regards,
Tony.

Thanks. I have solved the problem.
2006/11/25, A.J.Mechelynck <antoine.mechelynck@...>:
> ocean wrote:
> > When I set encoding to utf-8 and let $lang zh_CN.UTF-8, the tooltips
> > can't display correctly and the popup menu on tabpage also. I found
> > the problem is that the tool tips is utf-8 encoding, it should be
> > translated to active codepage encoding.
> >
>
> I may be wrong, but I think this problem was addressed by a recent bugfix.
> Which version and patchlevel are you using? (See the first five lines from the
> output of ":version"; and if there is no line starting "Included patches:" it
> means you are at patchlevel zero (no patches included).
>
> See at http://ftp.vim.org/pub/vim/patches/7.0/README a one-line summary of
> every bugfix published so far for Vim 7.0.
>
> For Windows, you can get an "updated" distribution at
> https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721
> -- see the "release notes" for the corresponding ":version" listing.
>
> If you want something even more recent, or a different choice of features, you
> can compile Vim yourself, see (for Windows)
> http://users.skynet.be/antoine.mechelynck/vim/compile.htm
>
>
> Best regards,
> Tony.
>

Hi! This is the ezmlm program. I'm managing the
vim-multibyte@... mailing list.

I'm working for my owner, who can be reached
at vim-multibyte-owner@....


Messages to you from the vim-multibyte mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

If this message bounces too, I will send you a probe. If the probe bounces,
I will remove your address from the vim-multibyte mailing list,
without further notice.


I've kept a list of which messages from the vim-multibyte mailing list have
bounced from your address.

Copies of these messages may be in the archive.
To retrieve a set of messages 123-145 (a maximum of 100 per request),
send an empty message to:
    <vim-multibyte-get.123_145@...>

To receive a subject and author list for the last 100 or so messages,
send an empty message to:
    <vim-multibyte-index@...>

Here are the message numbers:

    2249

--- Enclosed is a copy of the bounce message I received.

Return-Path: <>
Received: (qmail 1222 invoked for bounce); 28 Nov 2006 03:36:40 -0000
Date: 28 Nov 2006 03:36:40 -0000
From: MAILER-DAEMON@...
To: vim-multibyte-return-2249-@...
Subject: failure notice

Hi. This is the qmail-send program at foobar.math.fu-berlin.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<listsaver-of-vim-multibyte@yahoogroups.com>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.

Dear Vim users,

The traditional Vim calendar has been updated for 2007!

This is a desktop calendar for 2007, made from one sheet of paper.
After folding, one side contains a useful 12-month calendar.
On the other side there is brief information about ICCF-Holland,
Vim and A-A-P.

	 English, A4:     http://www.moolenaar.net/2007_en_a4.pdf
	 English, Letter: http://www.moolenaar.net/2007_en_le.pdf
	 Dutch, A4:       http://www.moolenaar.net/2007_nl_a4.pdf

Each file is in PDF and about 180 Kbyte.


I'm afraid the problem with scripts on www.vim.org has not been solved
yet.  We are waiting for SourceForge support...


Happy holidays!

--
It is illegal for anyone to try and stop a child from playfully jumping over
puddles of water.
		 [real standing law in California, United States of America]

  /// 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    ///

Hi,

I think I found a bug in Vim's UTF8 handling. I've spend 2 days debugging,
testing and hair pulling, but I coudn't find the solution the problem and now I
think it's a bug. I use Gentoo, Vim 7.0 and UTF8 in the kernel e.t.c. To debug
and check the following message I've compiled a fresh vim from the source, but
unfortunately the results are the same for either version (source and gentoo
build).

I've got a Python Vim script that fetches (wordpress) content via xmlrpc (the
xmlrpc-source has UTF8 encoding). After the content is fetched it is written to
the current buffer. This works fine, but when there are any strange characters
in the content the script fails (error below). I've deduced the script to the
following:

=================================================

if has('python')
     python << EOF
# -*- coding: utf-8 -*-

import vim

def foo():
     u = 'a'             # This works fine
     vim.current.buffer.append(u)

def bar():
     u = unichr(40960)    # But this doesn't
     vim.current.buffer.append(u)

EOF
endif

=================================================


When I call this in Vim, foo() works fine, "a" is appended at the end of the
buffer, but calling bar() results in the following error:

	 Traceback (most recent call last):
	   File "<string>", line 1, in ?
	   File "<string>", line 11, in bar
	 TypeError: bad argument type for built-in operation


I've started Vim in utf8 mode:

	 marijn@srv ~ $ export LC_ALL=en_US.utf8
	 marijn@srv ~ $ export LANG=en_US.utf8
	 marijn@srv ~ $ vim


So that can't be the problem.

I've also created a seperate file:

=================================================

#!/usr/bin/python
# -*- coding: utf8 -*-
# test.py
print unichr(40960)

=================================================

Running this in a shell with LC_ALL=en_EN.utf8 works fine, with LC_ALL=C it
fails, which is normal.

When running it in Vim ":!python test.py" works fine, the character is printed.
But when I try to insert it in the current buffer ": r !python test.py" it
fails:
"UnicodeEncodeError: *'ascii' codec* can't encode character u'ua000' in position
0: ordinal not in range(128)"

Maybe this is because of the 'r' function not handling UTF8 well
(http://vimdoc.sourceforge.net/htmldoc/mbyte.html#UTF-8), but I'm not sure of
that. But for completeness I wanted to include this as well.

I think this (especially the first part) is a bug of Vim, I hope you can
acknowledge this, and/or help to find a solution.


Tia and best wishes,

Marijn Koesen

Marijn wrote:
> Hi,
>
> I think I found a bug in Vim's UTF8 handling. I've spend 2 days debugging,
testing and hair pulling, but I coudn't find the solution the problem and now I
think it's a bug. I use Gentoo, Vim 7.0 and UTF8 in the kernel e.t.c. To debug
and check the following message I've compiled a fresh vim from the source, but
unfortunately the results are the same for either version (source and gentoo
build).
>
> I've got a Python Vim script that fetches (wordpress) content via xmlrpc (the
xmlrpc-source has UTF8 encoding). After the content is fetched it is written to
the current buffer. This works fine, but when there are any strange characters
in the content the script fails (error below). I've deduced the script to the
following:
>
> =================================================
>
> if has('python')
>     python << EOF
> # -*- coding: utf-8 -*-
>
> import vim
>
> def foo():
>     u = 'a'             # This works fine
>     vim.current.buffer.append(u)
>
> def bar():
>     u = unichr(40960)    # But this doesn't
>     vim.current.buffer.append(u)
>
> EOF
> endif
>
> =================================================
>
>
> When I call this in Vim, foo() works fine, "a" is appended at the end of the
buffer, but calling bar() results in the following error:
>
>  Traceback (most recent call last):
> 	  File "<string>", line 1, in ?
> 	  File "<string>", line 11, in bar
>  TypeError: bad argument type for built-in operation
>
>
> I've started Vim in utf8 mode:
>
>  marijn@srv ~ $ export LC_ALL=en_US.utf8
>  marijn@srv ~ $ export LANG=en_US.utf8
>  marijn@srv ~ $ vim
>
>
> So that can't be the problem.
>
> I've also created a seperate file:
>
> =================================================
>
> #!/usr/bin/python
> # -*- coding: utf8 -*-
> # test.py
> print unichr(40960)
>
> =================================================
>
> Running this in a shell with LC_ALL=en_EN.utf8 works fine, with LC_ALL=C it
fails, which is normal.
>
> When running it in Vim ":!python test.py" works fine, the character is
printed.
> But when I try to insert it in the current buffer ": r !python test.py" it
fails:
> "UnicodeEncodeError: *'ascii' codec* can't encode character u'ua000' in
position 0: ordinal not in range(128)"
>
> Maybe this is because of the 'r' function not handling UTF8 well
(http://vimdoc.sourceforge.net/htmldoc/mbyte.html#UTF-8), but I'm not sure of
that. But for completeness I wanted to include this as well.
>
> I think this (especially the first part) is a bug of Vim, I hope you can
acknowledge this, and/or help to find a solution.
>
>
> Tia and best wishes,
>
> Marijn Koesen
>

1. Is your Vim executable built with +multi_byte?
	 :echo has("multi_byte")
should answer 1
If the answer is zero, you should install a Vim executable with +multi_byte
compiled-in.

2. Do you have 'encoding' set to UTF-8?
	 :set enc?
should answer
	 encoding=utf-8
If the answer is something else (but it passes test 1 above), tell me what it
is and I'll tell you what to add to your vimrc.

If the answer to either question is "no", Vim cannot handle UTF-8 codepoints
above U+007F (or maybe U+00FF, depending).


Best regards,
Tony.

A.J.Mechelynck wrote:
> Marijn wrote:
>> Hi,
>>
>> I think I found a bug in Vim's UTF8 handling. I've spend 2 days debugging,
testing and hair pulling, but I coudn't find the solution the problem and now I
think it's a bug. I use Gentoo, Vim 7.0 and UTF8 in the kernel e.t.c. To debug
and check the following message I've compiled a fresh vim from the source, but
unfortunately the results are the same for either version (source and gentoo
build).
>>
>> I've got a Python Vim script that fetches (wordpress) content via xmlrpc (the
xmlrpc-source has UTF8 encoding). After the content is fetched it is written to
the current buffer. This works fine, but when there are any strange characters
in the content the script fails (error below). I've deduced the script to the
following:
>>
>> =================================================
>>
>> if has('python')
>>     python << EOF
>> # -*- coding: utf-8 -*-
>>
>> import vim
>>
>> def foo():
>>     u = 'a'             # This works fine
>>     vim.current.buffer.append(u)
>>
>> def bar():
>>     u = unichr(40960)    # But this doesn't
>>     vim.current.buffer.append(u)
>>
>> EOF
>> endif
>>
>> =================================================
>>
>>
>> When I call this in Vim, foo() works fine, "a" is appended at the end of the
buffer, but calling bar() results in the following error:
>>
>>     Traceback (most recent call last):
>>       File "<string>", line 1, in ?
>>       File "<string>", line 11, in bar
>>     TypeError: bad argument type for built-in operation
>>
>>
>> I've started Vim in utf8 mode:
>>
>>     marijn@srv ~ $ export LC_ALL=en_US.utf8
>>     marijn@srv ~ $ export LANG=en_US.utf8
>>     marijn@srv ~ $ vim
>>
>>
>> So that can't be the problem.
>>
>> I've also created a seperate file:
>>
>> =================================================
>>
>> #!/usr/bin/python
>> # -*- coding: utf8 -*-
>> # test.py
>> print unichr(40960)
>>
>> =================================================
>>
>> Running this in a shell with LC_ALL=en_EN.utf8 works fine, with LC_ALL=C it
fails, which is normal.
>>
>> When running it in Vim ":!python test.py" works fine, the character is
printed.
>> But when I try to insert it in the current buffer ": r !python test.py" it
fails: "UnicodeEncodeError: *'ascii' codec* can't encode character u'ua000' in
position 0: ordinal not in range(128)"
>>
>> Maybe this is because of the 'r' function not handling UTF8 well
(http://vimdoc.sourceforge.net/htmldoc/mbyte.html#UTF-8), but I'm not sure of
that. But for completeness I wanted to include this as well.
>>
>> I think this (especially the first part) is a bug of Vim, I hope you can
acknowledge this, and/or help to find a solution.
>>
>>
>> Tia and best wishes,
>>
>> Marijn Koesen
>>
>
> 1. Is your Vim executable built with +multi_byte?
>     :echo has("multi_byte")
> should answer 1
> If the answer is zero, you should install a Vim executable with +multi_byte
compiled-in.
>
> 2. Do you have 'encoding' set to UTF-8?
>     :set enc?
> should answer
>     encoding=utf-8
> If the answer is something else (but it passes test 1 above), tell me what it
is and I'll tell you what to add to your vimrc.
>
> If the answer to either question is "no", Vim cannot handle UTF-8 codepoints
above U+007F (or maybe U+00FF, depending).
>
>
> Best regards,
> Tony.
>


1) Yes, it's compiled with multi_byte:

Some more details about my vim version:

:version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Jan  2 2007 00:32:34)
Included patches: 1-17
Modified by Gentoo-7.0.17
Compiled by root@henk
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: "/etc/vim/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   fall-back for $VIM: "/usr/share/vim"
Compilation: i686-pc-linux-gnu-gcc -c -I. -Iproto -DHAVE_CONFIG_H    
-march=pentium3 -O2 -pipe -fomit-frame-pointer    -pipe
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-I/usr/lib/perl5/5.8.8/i686-linux/CORE  -I/usr/include/python2.4 -pthread 
-I/usr/
lib/ruby/1.8/i686-linux
Linking: i686-pc-linux-gnu-gcc   -rdynamic -Wl,-export-dynamic  -rdynamic  
-L/usr/local/lib -o vim       -lncurses -lgpm   -r
dynamic  -L/usr/local/lib
/usr/lib/perl5/5.8.8/i686-linux/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.8/i686-linux/CORE
-lperl -lutil -lc -L/usr/lib/python2.4/config -lpython2.4 -lpthread -lutil
-Xlinker -export-dynamic  -Wl,-R -Wl,/usr/lib -L/us
r/lib -L/usr/lib -lruby18 -lm


2) Yes, all the files that I have used and created have (had) the utf8 encoding.
I've tested all the files by "set enc".


Best regards,

Marijn

I'm interested in using Vim to edit files with Unicode supplementary
chars, like Shavian and Deseret Alphabet.

I have Vim 7.0 running and have written vim input methods to enter
such characters.  I can write the resulting files and have confirmed
that they really do contain the desired characters.

But the characters do not display in my vim windows.  I just see
question marks.  Not good.

Question:  is it just a matter of setting the right fonts? or is vim
still incapable of displaying Unicode supplementary chars?

Thanks,

Ken

Kenneth Reid Beesley wrote:
> I'm interested in using Vim to edit files with Unicode supplementary
> chars, like Shavian and Deseret Alphabet.
>
> I have Vim 7.0 running and have written vim input methods to enter
> such characters.  I can write the resulting files and have confirmed
> that they really do contain the desired characters.
>
> But the characters do not display in my vim windows.  I just see
> question marks.  Not good.
>
> Question:  is it just a matter of setting the right fonts? or is vim
> still incapable of displaying Unicode supplementary chars?
>
> Thanks,
>
> Ken
>

I think that Vim is incapabale of displaying codepoints above U+FFFF, but I'm
not 100% sure. It is a problem for CJK too, since some hanzi are in plane 2
(U+2xxxx).

Of course, any codepoints for which your 'guifont' has no glyph (or, in GTK2
versions, for which Xft cannot find a glyph) can never be displayed.


Best regards,
Tony.

Marijn wrote:
> A.J.Mechelynck wrote:
>> Marijn wrote:
>>> A.J.Mechelynck wrote:
>>>> Marijn wrote:
>>>>> Hi,
>>>>>
>>>>> I think I found a bug in Vim's UTF8 handling. I've spend 2 days debugging,
testing and hair pulling, but I coudn't find the solution the problem and now I
think it's a bug. I use Gentoo, Vim 7.0 and UTF8 in the kernel e.t.c. To debug
and check the following message I've compiled a fresh vim from the source, but
unfortunately the results are the same for either version (source and gentoo
build).
>>>>>
>>>>> I've got a Python Vim script that fetches (wordpress) content via xmlrpc
(the xmlrpc-source has UTF8 encoding). After the content is fetched it is
written to the current buffer. This works fine, but when there are any strange
characters in the content the script fails (error below). I've deduced the
script to the following:
>>>>>
>>>>> =================================================
>>>>>
>>>>> if has('python')
>>>>>     python << EOF
>>>>> # -*- coding: utf-8 -*-
>>>>>
>>>>> import vim
>>>>>
>>>>> def foo():
>>>>>     u = 'a'             # This works fine
>>>>>     vim.current.buffer.append(u)
>>>>>
>>>>> def bar():
>>>>>     u = unichr(40960)    # But this doesn't
>>>>>     vim.current.buffer.append(u)
>>>>>
>>>>> EOF
>>>>> endif
>>>>>
>>>>> =================================================
>>>>>
>>>>>
>>>>> When I call this in Vim, foo() works fine, "a" is appended at the end of
the buffer, but calling bar() results in the following error:
>>>>>
>>>>>     Traceback (most recent call last):
>>>>>       File "<string>", line 1, in ?
>>>>>       File "<string>", line 11, in bar
>>>>>     TypeError: bad argument type for built-in operation
>>>>>
>>>>>
>>>>> I've started Vim in utf8 mode:
>>>>>
>>>>>     marijn@srv ~ $ export LC_ALL=en_US.utf8
>>>>>     marijn@srv ~ $ export LANG=en_US.utf8
>>>>>     marijn@srv ~ $ vim
>>>>>
>>>>>
>>>>> So that can't be the problem.
>>>>>
>>>>> I've also created a seperate file:
>>>>>
>>>>> =================================================
>>>>>
>>>>> #!/usr/bin/python
>>>>> # -*- coding: utf8 -*-
>>>>> # test.py   print unichr(40960)
>>>>>
>>>>> =================================================
>>>>>
>>>>> Running this in a shell with LC_ALL=en_EN.utf8 works fine, with LC_ALL=C
it fails, which is normal.
>>>>>
>>>>> When running it in Vim ":!python test.py" works fine, the character is
printed.
>>>>> But when I try to insert it in the current buffer ": r !python test.py" it
fails: "UnicodeEncodeError: *'ascii' codec* can't encode character u'ua000' in
position 0: ordinal not in range(128)"
>>>>>
>>>>> Maybe this is because of the 'r' function not handling UTF8 well
(http://vimdoc.sourceforge.net/htmldoc/mbyte.html#UTF-8), but I'm not sure of
that. But for completeness I wanted to include this as well.
>> The last paragrapg there (about 'guifontwide' etc.) seems inaccurate. I have
the same at ":help Unicode" in the Vim help but IMHO what is said under ":help
'guifontwide'" seems more accurate. Even though 'guifontwide' is not set my gvim
uses wide glyphs for wide characters. Maybe because my Chinese 'guifont' has
them.
>>
>>>>> I think this (especially the first part) is a bug of Vim, I hope you can
acknowledge this, and/or help to find a solution.
>>>>>
>>>>>
>>>>> Tia and best wishes,
>>>>>
>>>>> Marijn Koesen
>>>>>
>>>> 1. Is your Vim executable built with +multi_byte?
>>>>     :echo has("multi_byte")
>>>> should answer 1
>>>> If the answer is zero, you should install a Vim executable with +multi_byte
compiled-in.
>>>>
>>>> 2. Do you have 'encoding' set to UTF-8?
>>>>     :set enc?
>>>> should answer
>>>>     encoding=utf-8
>>>> If the answer is something else (but it passes test 1 above), tell me what
it is and I'll tell you what to add to your vimrc.
>>>>
>>>> If the answer to either question is "no", Vim cannot handle UTF-8
codepoints above U+007F (or maybe U+00FF, depending).
>>>>
>>>>
>>>> Best regards,
>>>> Tony.
>>>>
>>>
>>> 1) Yes, it's compiled with multi_byte:
>>>
>>> Some more details about my vim version:
>>>
>>> :version
>>> VIM - Vi IMproved 7.0 (2006 May 7, compiled Jan  2 2007 00:32:34)
>>> Included patches: 1-17
>>> Modified by Gentoo-7.0.17
>>> Compiled by root@henk
>> [...]
>> That one (7.0.017) isn't very recent anymore. The current release is 7.0.178.
See the "table of contents" of the bugfixes at
http://ftp.vim.org/pub/vim/patches/7.0/README
>>>
>>> 2) Yes, all the files that I have used and created have (had) the utf8
encoding. I've tested all the files by "set enc".
>>>
>>>
>>> Best regards,
>>>
>>> Marijn
>>>
>> 'enc' defines the _internal_ encoding used by Vim to represent the characters
_internally_ in memory. The charset of an edited file can be different. Open the
buffer where you were trying to add data by means of that python script and use
>>
>>     :verbose set enc? fenc?
>>
>> What is the reply?
>>
>>
>> Best regards,
>> Tony.
>>
>
> Thanks for the reply Tony, but everything is really utf8:
>
> All the files return:
>   encoding=utf-8
>   fileencoding=utf-8
>
>
> Best regards,
> Marijn
>


>> That one (7.0.017) isn't very recent anymore. The current release is 7.0.178.
See the "table of contents" of the bugfixes at
http://ftp.vim.org/pub/vim/patches/7.0/README

I've just fetched all the patches, patched vim and tried it again:

VIM - Vi IMproved 7.0 (2006 May 7, compiled Jan  4 2007 19:12:01)
Included patches: 1-178
Compiled by joost@henk
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 +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_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: "/home/joost/vim7/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -DXTHREADS
-D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/inclu
de/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include     -g -O2     -I/usr/i
nclude/python2.4 -pthread
Linking: gcc   -L/usr/local/lib -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0
-lglib-2.0   -lXt -lncurses -lgpm    -L/usr/lib/python2.4/config -lpython2.4
-lpthread -ldl -lutil -lm -Xlinker -export-dynamic




But the following script

===========================
#!/usr/bin/python
# -*- coding: utf8 -*-
print unichr(40960)
===========================

In vim: "r !python test.py" gives the same: "'ascii' codec can't encode
character" error.

Also:

===========================
def bar():
     u = unichr(40960)
     vim.current.buffer.append(u)
===========================

Still gives the "TypeError: bad argument type for built-in operation" error.


Best regards,
Marijn

A.J.Mechelynck wrote:
> Marijn wrote:
>> A.J.Mechelynck wrote:
>>> Marijn wrote:
>>>> Hi,
>>>>
>>>> I think I found a bug in Vim's UTF8 handling. I've spend 2 days debugging,
testing and hair pulling, but I coudn't find the solution the problem and now I
think it's a bug. I use Gentoo, Vim 7.0 and UTF8 in the kernel e.t.c. To debug
and check the following message I've compiled a fresh vim from the source, but
unfortunately the results are the same for either version (source and gentoo
build).
>>>>
>>>> I've got a Python Vim script that fetches (wordpress) content via xmlrpc
(the xmlrpc-source has UTF8 encoding). After the content is fetched it is
written to the current buffer. This works fine, but when there are any strange
characters in the content the script fails (error below). I've deduced the
script to the following:
>>>>
>>>> =================================================
>>>>
>>>> if has('python')
>>>>     python << EOF
>>>> # -*- coding: utf-8 -*-
>>>>
>>>> import vim
>>>>
>>>> def foo():
>>>>     u = 'a'             # This works fine
>>>>     vim.current.buffer.append(u)
>>>>
>>>> def bar():
>>>>     u = unichr(40960)    # But this doesn't
>>>>     vim.current.buffer.append(u)
>>>>
>>>> EOF
>>>> endif
>>>>
>>>> =================================================
>>>>
>>>>
>>>> When I call this in Vim, foo() works fine, "a" is appended at the end of
the buffer, but calling bar() results in the following error:
>>>>
>>>>     Traceback (most recent call last):
>>>>       File "<string>", line 1, in ?
>>>>       File "<string>", line 11, in bar
>>>>     TypeError: bad argument type for built-in operation
>>>>
>>>>
>>>> I've started Vim in utf8 mode:
>>>>
>>>>     marijn@srv ~ $ export LC_ALL=en_US.utf8
>>>>     marijn@srv ~ $ export LANG=en_US.utf8
>>>>     marijn@srv ~ $ vim
>>>>
>>>>
>>>> So that can't be the problem.
>>>>
>>>> I've also created a seperate file:
>>>>
>>>> =================================================
>>>>
>>>> #!/usr/bin/python
>>>> # -*- coding: utf8 -*-
>>>> # test.py   print unichr(40960)
>>>>
>>>> =================================================
>>>>
>>>> Running this in a shell with LC_ALL=en_EN.utf8 works fine, with LC_ALL=C it
fails, which is normal.
>>>>
>>>> When running it in Vim ":!python test.py" works fine, the character is
printed.
>>>> But when I try to insert it in the current buffer ": r !python test.py" it
fails: "UnicodeEncodeError: *'ascii' codec* can't encode character u'ua000' in
position 0: ordinal not in range(128)"
>>>>
>>>> Maybe this is because of the 'r' function not handling UTF8 well
(http://vimdoc.sourceforge.net/htmldoc/mbyte.html#UTF-8), but I'm not sure of
that. But for completeness I wanted to include this as well.
>
> The last paragrapg there (about 'guifontwide' etc.) seems inaccurate. I have
the same at ":help Unicode" in the Vim help but IMHO what is said under ":help
'guifontwide'" seems more accurate. Even though 'guifontwide' is not set my gvim
uses wide glyphs for wide characters. Maybe because my Chinese 'guifont' has
them.
>
>>>>
>>>> I think this (especially the first part) is a bug of Vim, I hope you can
acknowledge this, and/or help to find a solution.
>>>>
>>>>
>>>> Tia and best wishes,
>>>>
>>>> Marijn Koesen
>>>>
>>> 1. Is your Vim executable built with +multi_byte?
>>>     :echo has("multi_byte")
>>> should answer 1
>>> If the answer is zero, you should install a Vim executable with +multi_byte
compiled-in.
>>>
>>> 2. Do you have 'encoding' set to UTF-8?
>>>     :set enc?
>>> should answer
>>>     encoding=utf-8
>>> If the answer is something else (but it passes test 1 above), tell me what
it is and I'll tell you what to add to your vimrc.
>>>
>>> If the answer to either question is "no", Vim cannot handle UTF-8 codepoints
above U+007F (or maybe U+00FF, depending).
>>>
>>>
>>> Best regards,
>>> Tony.
>>>
>>
>>
>> 1) Yes, it's compiled with multi_byte:
>>
>> Some more details about my vim version:
>>
>> :version
>> VIM - Vi IMproved 7.0 (2006 May 7, compiled Jan  2 2007 00:32:34)
>> Included patches: 1-17
>> Modified by Gentoo-7.0.17
>> Compiled by root@henk
> [...]
> That one (7.0.017) isn't very recent anymore. The current release is 7.0.178.
See the "table of contents" of the bugfixes at
http://ftp.vim.org/pub/vim/patches/7.0/README
>>
>>
>> 2) Yes, all the files that I have used and created have (had) the utf8
encoding. I've tested all the files by "set enc".
>>
>>
>> Best regards,
>>
>> Marijn
>>
>
> 'enc' defines the _internal_ encoding used by Vim to represent the characters
_internally_ in memory. The charset of an edited file can be different. Open the
buffer where you were trying to add data by means of that python script and use
>
>     :verbose set enc? fenc?
>
> What is the reply?
>
>
> Best regards,
> Tony.
>

Thanks for the reply Tony, but everything is really utf8:

All the files return:
   encoding=utf-8
   fileencoding=utf-8


Best regards,
Marijn

Marijn wrote:
> A.J.Mechelynck wrote:
>> Marijn wrote:
>>> Hi,
>>>
>>> I think I found a bug in Vim's UTF8 handling. I've spend 2 days debugging,
testing and hair pulling, but I coudn't find the solution the problem and now I
think it's a bug. I use Gentoo, Vim 7.0 and UTF8 in the kernel e.t.c. To debug
and check the following message I've compiled a fresh vim from the source, but
unfortunately the results are the same for either version (source and gentoo
build).
>>>
>>> I've got a Python Vim script that fetches (wordpress) content via xmlrpc
(the xmlrpc-source has UTF8 encoding). After the content is fetched it is
written to the current buffer. This works fine, but when there are any strange
characters in the content the script fails (error below). I've deduced the
script to the following:
>>>
>>> =================================================
>>>
>>> if has('python')
>>>     python << EOF
>>> # -*- coding: utf-8 -*-
>>>
>>> import vim
>>>
>>> def foo():
>>>     u = 'a'             # This works fine
>>>     vim.current.buffer.append(u)
>>>
>>> def bar():
>>>     u = unichr(40960)    # But this doesn't
>>>     vim.current.buffer.append(u)
>>>
>>> EOF
>>> endif
>>>
>>> =================================================
>>>
>>>
>>> When I call this in Vim, foo() works fine, "a" is appended at the end of the
buffer, but calling bar() results in the following error:
>>>
>>>     Traceback (most recent call last):
>>>       File "<string>", line 1, in ?
>>>       File "<string>", line 11, in bar
>>>     TypeError: bad argument type for built-in operation
>>>
>>>
>>> I've started Vim in utf8 mode:
>>>
>>>     marijn@srv ~ $ export LC_ALL=en_US.utf8
>>>     marijn@srv ~ $ export LANG=en_US.utf8
>>>     marijn@srv ~ $ vim
>>>
>>>
>>> So that can't be the problem.
>>>
>>> I've also created a seperate file:
>>>
>>> =================================================
>>>
>>> #!/usr/bin/python
>>> # -*- coding: utf8 -*-
>>> # test.py
>>> print unichr(40960)
>>>
>>> =================================================
>>>
>>> Running this in a shell with LC_ALL=en_EN.utf8 works fine, with LC_ALL=C it
fails, which is normal.
>>>
>>> When running it in Vim ":!python test.py" works fine, the character is
printed.
>>> But when I try to insert it in the current buffer ": r !python test.py" it
fails: "UnicodeEncodeError: *'ascii' codec* can't encode character u'ua000' in
position 0: ordinal not in range(128)"
>>>
>>> Maybe this is because of the 'r' function not handling UTF8 well
(http://vimdoc.sourceforge.net/htmldoc/mbyte.html#UTF-8), but I'm not sure of
that. But for completeness I wanted to include this as well.

The last paragrapg there (about 'guifontwide' etc.) seems inaccurate. I have
the same at ":help Unicode" in the Vim help but IMHO what is said under ":help
'guifontwide'" seems more accurate. Even though 'guifontwide' is not set my
gvim uses wide glyphs for wide characters. Maybe because my Chinese 'guifont'
has them.

>>>
>>> I think this (especially the first part) is a bug of Vim, I hope you can
acknowledge this, and/or help to find a solution.
>>>
>>>
>>> Tia and best wishes,
>>>
>>> Marijn Koesen
>>>
>> 1. Is your Vim executable built with +multi_byte?
>>     :echo has("multi_byte")
>> should answer 1
>> If the answer is zero, you should install a Vim executable with +multi_byte
compiled-in.
>>
>> 2. Do you have 'encoding' set to UTF-8?
>>     :set enc?
>> should answer
>>     encoding=utf-8
>> If the answer is something else (but it passes test 1 above), tell me what it
is and I'll tell you what to add to your vimrc.
>>
>> If the answer to either question is "no", Vim cannot handle UTF-8 codepoints
above U+007F (or maybe U+00FF, depending).
>>
>>
>> Best regards,
>> Tony.
>>
>
>
> 1) Yes, it's compiled with multi_byte:
>
> Some more details about my vim version:
>
> :version
> VIM - Vi IMproved 7.0 (2006 May 7, compiled Jan  2 2007 00:32:34)
> Included patches: 1-17
> Modified by Gentoo-7.0.17
> Compiled by root@henk
[...]
That one (7.0.017) isn't very recent anymore. The current release is 7.0.178.
See the "table of contents" of the bugfixes at
http://ftp.vim.org/pub/vim/patches/7.0/README
>
>
> 2) Yes, all the files that I have used and created have (had) the utf8
encoding. I've tested all the files by "set enc".
>
>
> Best regards,
>
> Marijn
>

'enc' defines the _internal_ encoding used by Vim to represent the characters
_internally_ in memory. The charset of an edited file can be different. Open
the buffer where you were trying to add data by means of that python script
and use

	 :verbose set enc? fenc?

What is the reply?


Best regards,
Tony.

Marijn wrote:

> But the following script
>
> ===========================
> #!/usr/bin/python
> # -*- coding: utf8 -*-
> print unichr(40960)
> ===========================
>
> In vim: "r !python test.py" gives the same: "'ascii' codec can't
> encode character" error.

The problem is in Python, this is a Python error message.  This has
nothing to do with Vim.

I guess you somehow have to put Python in utf-8 mode first.  This page
appears to provide info: http://www.amk.ca/python/howto/unicode

> Also:
>
> ===========================
> def bar():
>     u = unichr(40960)
>     vim.current.buffer.append(u)
> ===========================
>
> Still gives the "TypeError: bad argument type for built-in operation" error.

Here "u" is of type "unicode", while the append() function requires a
string.  Perhaps Python has a function to convert type "unicode" to a
string with utf-8 characters?

--
If you had to identify, in one word, the reason why the
human race has not achieved, and never will achieve, its
full potential, that word would be "meetings."

  /// 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    ///

Bram Moolenaar wrote:
> Marijn wrote:
>
>> But the following script
>>
>> ===========================
>> #!/usr/bin/python
>> # -*- coding: utf8 -*-
>> print unichr(40960)
>> ===========================
>>
>> In vim: "r !python test.py" gives the same: "'ascii' codec can't
>> encode character" error.
>
> The problem is in Python, this is a Python error message.  This has
> nothing to do with Vim.
>
> I guess you somehow have to put Python in utf-8 mode first.  This page
> appears to provide info: http://www.amk.ca/python/howto/unicode
>

You were correct. Thanks a million.


>> Also:
>>
>> ===========================
>> def bar():
>>     u = unichr(40960)
>>     vim.current.buffer.append(u)
>> ===========================
>>
>> Still gives the "TypeError: bad argument type for built-in operation" error.
>
> Here "u" is of type "unicode", while the append() function requires a
> string.  Perhaps Python has a function to convert type "unicode" to a
> string with utf-8 characters?
>

I added: "u.encode('utf-8')" and it worked flawlessly. After adding the same to
my original code, that worked as well. I guess I didn't understand unicode too
well after all... after reading you link everything felt in place. Python tried
to pass unicode instead of utf8 strings. Sorry for the troubles, but thanks a
lot.


Best regards,
Marijn

:print command shows multibyte character preceded by Tab with same color
as Tab.  To reset attribute for multibyte character is forgotten.
It seems that the current code intend to show multibyte character always
with normal color.  So I think that attribute can be omitted.

*** message.c.orig Thu Jan 11 22:53:19 2007
--- message.c Thu Jan 11 22:53:19 2007
***************
*** 1595,1601 ****
  	     col += (*mb_ptr2cells)(s);
  	     mch_memmove(buf, s, (size_t)l);
  	     buf[l] = NUL;
! 	    msg_puts_attr(buf, attr);
  	     s += l;
  	     continue;
  	 }
--- 1595,1601 ----
  	     col += (*mb_ptr2cells)(s);
  	     mch_memmove(buf, s, (size_t)l);
  	     buf[l] = NUL;
! 	    msg_puts(buf);
  	     s += l;
  	     continue;
  	 }


And I wonder why ^I or <hex> formed special character is shown with
normal color.  Does the following line can be added?

*** message.c.orig Thu Jan 11 22:53:19 2007
--- message.c Thu Jan 11 22:53:19 2007
***************
*** 1635,1640 ****
--- 1635,1641 ----
  		 p_extra = transchar_byte(c);
  		 c_extra = NUL;
  		 c = *p_extra++;
+ 	 attr = hl_attr(HLF_8);
  	     }
  	     else if (c == ' ' && trail != NULL && s > trail)
  	     {


--
Yukihiro Nakadaira - yukihiro.nakadaira@...

Yukihiro Nakadaira wrote:
> :print command shows multibyte character preceded by Tab with same color
> as Tab.  To reset attribute for multibyte character is forgotten.
> It seems that the current code intend to show multibyte character always
> with normal color.  So I think that attribute can be omitted.

Yes, at the moment I see multibyte chars (between tabs) in blue if 'list' is
on and 'listchars' includes a "tab:" part. If 'list' is off, or if 'listchars'
does not include "tab:", the same multibyte chars are in black (using the
default GUI colors).

Best regards,
Tony.

>
> *** message.c.orig Thu Jan 11 22:53:19 2007
> --- message.c Thu Jan 11 22:53:19 2007
> ***************
> *** 1595,1601 ****
>   	    col += (*mb_ptr2cells)(s);
>   	    mch_memmove(buf, s, (size_t)l);
>   	    buf[l] = NUL;
> ! 	    msg_puts_attr(buf, attr);
>   	    s += l;
>   	    continue;
>    }
> --- 1595,1601 ----
>   	    col += (*mb_ptr2cells)(s);
>   	    mch_memmove(buf, s, (size_t)l);
>   	    buf[l] = NUL;
> ! 	    msg_puts(buf);
>   	    s += l;
>   	    continue;
>    }
>
>
> And I wonder why ^I or <hex> formed special character is shown with
> normal color.  Does the following line can be added?
>
> *** message.c.orig Thu Jan 11 22:53:19 2007
> --- message.c Thu Jan 11 22:53:19 2007
> ***************
> *** 1635,1640 ****
> --- 1635,1641 ----
>   	 p_extra = transchar_byte(c);
>   	 c_extra = NUL;
>   	 c = *p_extra++;
> + 	 attr = hl_attr(HLF_8);
>   	    }
>   	    else if (c == ' ' && trail != NULL && s > trail)
>   	    {
>
>

Yukihiro Nakadaira wrote:

> :print command shows multibyte character preceded by Tab with same color
> as Tab.  To reset attribute for multibyte character is forgotten.
> It seems that the current code intend to show multibyte character always
> with normal color.  So I think that attribute can be omitted.

Yes, that is a good fix.

> And I wonder why ^I or <hex> formed special character is shown with
> normal color.  Does the following line can be added?

This will make it clear what is literal text and what is translated.  I
suppose this will be an improvement.

--
How To Keep A Healthy Level Of Insanity:
11. Specify that your drive-through order is "to go".

  /// 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    ///

According to src/edit.c

4971  if (compl_curr_match->cp_number != -1)
4972  {
4973      /* Space for 10 text chars. + 2x10-digit no.s */
4974      static char_u match_ref[31];
4975
4976      if (compl_matches > 0)
4977          sprintf((char *)IObuff, _("match %d of %d"),
4978                      compl_curr_match->cp_number, compl_matches);
4979      else
4980          sprintf((char *)IObuff, _("match %d"),
4981                                       compl_curr_match->cp_number);
4982      vim_strncpy(match_ref, IObuff, 30);

This message "match %d of %d" is stored into the buffer named match_ref
which have bytes for 30 chars.  But 30 bytes is not enough to be used to
store the translated multibyte message.  In Japanese locale this message
is truncated.  Current Japanese message in ja.po requires 46 bytes (26
text bytes + 2x10-digit) in Japanese DBCS encoding and 56 bytes in utf-8
encoding.  Maybe 30 bytes is also not enough for other language.  Could
you increase the buffer size?

--
Yukihiro Nakadaira - yukihiro.nakadaira@...

Yukihiro Nakadaira wrote:

> According to src/edit.c
>
> 4971  if (compl_curr_match->cp_number != -1)
> 4972  {
> 4973      /* Space for 10 text chars. + 2x10-digit no.s */
> 4974      static char_u match_ref[31];
> 4975
> 4976      if (compl_matches > 0)
> 4977          sprintf((char *)IObuff, _("match %d of %d"),
> 4978                      compl_curr_match->cp_number, compl_matches);
> 4979      else
> 4980          sprintf((char *)IObuff, _("match %d"),
> 4981                                       compl_curr_match->cp_number);
> 4982      vim_strncpy(match_ref, IObuff, 30);
>
> This message "match %d of %d" is stored into the buffer named match_ref
> which have bytes for 30 chars.  But 30 bytes is not enough to be used to
> store the translated multibyte message.  In Japanese locale this message
> is truncated.  Current Japanese message in ja.po requires 46 bytes (26
> text bytes + 2x10-digit) in Japanese DBCS encoding and 56 bytes in utf-8
> encoding.  Maybe 30 bytes is also not enough for other language.  Could
> you increase the buffer size?

Yes, the size is too small for translated messages.  Also, we can now
use vim_snprintf() instead of using IObuff.  Please try this patch:

*** ../vim-7.0.188/src/edit.c Wed Nov  1 21:24:58 2006
--- src/edit.c Fri Jan 19 20:22:09 2007
***************
*** 4970,4985 ****
  	      * just a safety check. */
  	     if (compl_curr_match->cp_number != -1)
  	     {
! 	 /* Space for 10 text chars. + 2x10-digit no.s */
! 	 static char_u match_ref[31];

  		 if (compl_matches > 0)
! 		    sprintf((char *)IObuff, _("match %d of %d"),
  				 compl_curr_match->cp_number, compl_matches);
  		 else
! 		    sprintf((char *)IObuff, _("match %d"),
! 						 compl_curr_match->cp_number);
! 	 vim_strncpy(match_ref, IObuff, 30);
  		 edit_submode_extra = match_ref;
  		 edit_submode_highl = HLF_R;
  		 if (dollar_vcol)
--- 4970,4987 ----
  	      * just a safety check. */
  	     if (compl_curr_match->cp_number != -1)
  	     {
! 	 /* Space for 10 text chars. + 2x10-digit no.s = 31.
! 		 * Translations may need more than twice that. */
! 	 static char_u match_ref[81];

  		 if (compl_matches > 0)
! 		    vim_snprintf((char *)match_ref, sizeof(match_ref),
! 			 _("match %d of %d"),
  				 compl_curr_match->cp_number, compl_matches);
  		 else
! 		    vim_snprintf((char *)match_ref, sizeof(match_ref),
! 			 _("match %d"),
! 			 compl_curr_match->cp_number);
  		 edit_submode_extra = match_ref;
  		 edit_submode_highl = HLF_R;
  		 if (dollar_vcol)


--
Nothing is fool-proof to a sufficiently talented fool.

  /// 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    ///

Bram Moolenaar wrote:
> Yes, the size is too small for translated messages.  Also, we can now
> use vim_snprintf() instead of using IObuff.  Please try this patch:

I tried that patch and it worked.  Thank you.

--
Yukihiro Nakadaira - yukihiro.nakadaira@...

Dear Vim users,

I will be doing a presentation on Vim, here is the announcement:


Open Source Developers @ Google Speaker Series: Bram Moolenaar

Tuesday, February 13, 19.00h

Title: Seven habits for effective text editing, 2.0.


Bram's presentation will give an overview of several ways to effectively
use Vim to edit programs, structured text and documentation.

Please join us for Bram's presentation if you're in the area. Doors will
open at 6:30 PM and Bram will begin speaking at 7:00 PM. Refreshments
will be served; please plan to sign in at Building 41 reception when you
arrive.


More information:
http://google-code-updates.blogspot.com/2007/02/open-source-developers-google-sp\
eaker.html

For instructions how to get there click on "Mountain View headquarters".
But pay attention to the building number 41, there are many Google
buildings :-).


Hope to meet you there!

--
From "know your smileys":
  <<<:-{    Worf (Never smiles anyways, so he's a bad smiley)

  /// 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    ///

The message cannot be represented in 7-bit ASCII encoding and has been sent as a
binary attachment.

Dear Vim users,

I will be doing a presentation on Vim, here is the announcement again:


Open Source Developers @ Google Speaker Series: Bram Moolenaar

Tuesday, February 13, 19.00h (7 pm)

Title: Seven habits for effective text editing, 2.0.


Bram's presentation will give an overview of several ways to effectively
use Vim to edit programs, structured text and documentation.

Please join us for Bram's presentation if you're in the area. Doors will
open at 6:30 PM and Bram will begin speaking at 7:00 PM. Refreshments
will be served; please plan to sign in at Building 41 reception (aka
lobby) when you arrive.


More information:
http://google-code-updates.blogspot.com/2007/02/open-source-developers-google-sp\
eaker.html

For instructions how to get there click on "Mountain View headquarters".
Pay attention to the building number: 41, there are many Google
buildings :-).

To be clear: this presentation is open to everyone.

Hope to meet you there!

:wq

--
hundred-and-one symptoms of being an internet addict:
107. When using your phone you forget that you don't have to use your
      keyboard.

  /// 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    ///

Dear Vim users,

A week ago I did a presentation on Vim, called "Seven habits of
effective text editing 2.0".  I was happy to see a lot of people
come to listen to me.  Many more than expected, we ran out of food and
had to get extra chairs.  Thanks to all who were there, it was nice to
have a big audience.  And I was excited to greet some of the people who
I previously only knew through e-mail.

The video of the presentation is now available on Google video:
http://video.google.com/videoplay?docid=2538831956647446078

The presentation itself is about 45 minutes.  With the Q&A included it
is 80 minutes.

If you can't use Google video, you may get the video file from the ftp
server: ftp://ftp.vim.org/pub/vim/stuff/7Habits20.avi
This is 507 Mbyte of divx.  You may want to use a mirror site:
ftp://ftp.vim.org/pub/vim/MIRRORS

It's a lot quicker to get the PDF with the presentation and notes:
http://www.moolenaar.net/habits.pdf
This is about 640 Kbyte.

--
hundred-and-one symptoms of being an internet addict:
163. You go outside for the fresh air (at -30 degrees) but open the
      window first to hear new mail arrive.

  /// 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    ///

I wrote:

> It's a lot quicker to get the PDF with the presentation and notes:
> http://www.moolenaar.net/habits.pdf
> This is about 640 Kbyte.

But that's the old one!  Use this link instead:
http://www.moolenaar.net/habits_2007.pdf

Oh, and in case you are interested in the books mentioned, use this
link: http://iccf-holland.org/click2.html

Sorry for the confusion.

--
hundred-and-one symptoms of being an internet addict:
168. You have your own domain name.

  /// 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 got a new message.


+++ Attachment: No Virus found
+++ Bitdefender AntiVirus - www.bitdefender.com