Re: A question on langmenu setting
On 6/14/06, Ge [EMAIL PROTECTED] wrote: I follow its direction, add this script to _vimrc: if has(gui_win32) NT Windows try language messages en finally set langmenu=none endtry endif Now the menu in Vim is not in English, what's wrong with my script? could anyone point it out, thanks. Here is the content of my _vimrc : set nocompatible source $VIMRUNTIME/vimrc_example.vim source $VIMRUNTIME/mswin.vim behave mswin if has(gui_win32) NT Windows try language messages en finally set langmenu=none endtry endif [snipped] Try putting these lines before sourcing vimrc_example.vim. The menu is already loaded when executing 'language messages en, so the menu is not affected. Another way is runtime! delmenu.vim *after* setting the message language. Yet another way is using the environment variable LANG without changing your _vimrc. For English, just set LANG=en. Best regards, -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: R: Vim doesn't open files with chinese file names
On 6/11/06, Wu Yongwei [EMAIL PROTECTED] wrote: On 6/11/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Cesar Romani wrote: -Messaggio originale- Da: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Inviato: venerdì 9 giugno 2006 23.34 A: Cesar Romani Cc: Vim Oggetto: Re: Vim doesn't open files with chinese file names Cesar Romani wrote: If I have a file with a chinese file name, f.e. 感情包袱.txt It won't open but it throws the message: E303: Unable to open swap file for .txt, recovery impossible Instead with notepad I can open the file. Many thanks in advance, Andalou Is your Vim version compiled with +multi_byte ? (:echo has(multi_byte) should return 1). The multi-byte feature is also mentioned in the :version text as one of +multi_byte, +multi_byte_ime or +multi_byte_ime/dyn If yes, check near the bottom of the :version text the name of the compiler: Vim binaries compiled with BCC32 have been notorious in the past for bad support of multi-byte characters, especially in filenames; IIUC, other compilers such as gcc and (don't remember the compiler executable name) MS Visual C have less problems in that respect. (I could be wrong though; I don't use non-Latin1 filenames and only very rarely non-7-bit-ASCII ones.) If has(multi_byte) is nonzero and it wasn't compiled with BCC32 then I don't know what it is -- maybe a bug. In this case, a makeshift workaround (until Bram fixes it) would be to rename the file back and forth to something with only 7-bit ASCII in the name. Normally, E303 means the swapfile can't be opened; but you should still be able to edit the file itself, unless it is very large. But you won't get a recovery option if Vim crashes, so don't forget to save your work extra often. Oh, and you are using a recent version of Vim aren't you? A year or two ago Vim just couldn't handle filenames with multibyte characters in them, but I thought that bug had been fixed. Best regards, Tony. Thanks for your answer, I use the vim 7.0 compiled with MS Visual C and it has multibyte. echo has(multi_byte) return 1. The file won't be opened and can't be edited even though the file is small. All what I get is an empty file. If I rename the file with ASCII, even with accented file name it will be opened. But notepad can open and edit it. Many thanks in advance, Andalou I now see the problem. You code page is not 936, right? Vim seems only able to open files with names that are valid in the current code page, as are many other applications that do not use the Unicode version of Windows APIs. This is an OS-related issue. You should not have such problems when the system locale uses UTF-8, such as modern Linux distros. One correction. This failure only occurs on the command line. :set encoding=utf-8, and you can open the file with :e successfully. -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: corrupted lines
On 6/11/06, Hari Krishna Dara [EMAIL PROTECTED] wrote:
While modifying one of my plugins, I had to add a new variable, and so
copy pasted some existing code and modified the name of the variable, so
it looked like this:
exists('g:lookupfile_LookupNotifyFunc')
The function that should be notified when a file is selected.
let g:lookupfile_LookupNotifyFunc = ''
endif
Since I modified only the name of the variable (and the comment), the
rest is not touched. I saved the file, and later when I came back to it,
this was how it was:
exists('g:lookupfile_LookupNotifyFunc')
The function that should be notified when a file is selected.
yrg t:ybbxhcsvyr_YbbxhcAbgvslShap = ''
raqvs
I can't believe that I have fat-fingered so badly for this to get so
badly transformed, can this be due to some bug in Vim?
It's ROT13'd: a - n, b - o, c - p, etc. So it does not look like
a bug of Vim, but rather some plugin was in effect.
Best regards,
Yongwei
Re: R: Vim doesn't open files with chinese file names
On 6/11/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Cesar Romani wrote: -Messaggio originale- Da: A.J.Mechelynck [mailto:[EMAIL PROTECTED] Inviato: venerdì 9 giugno 2006 23.34 A: Cesar Romani Cc: Vim Oggetto: Re: Vim doesn't open files with chinese file names Cesar Romani wrote: If I have a file with a chinese file name, f.e. 感情包袱.txt It won't open but it throws the message: E303: Unable to open swap file for .txt, recovery impossible Instead with notepad I can open the file. Many thanks in advance, Andalou Is your Vim version compiled with +multi_byte ? (:echo has(multi_byte) should return 1). The multi-byte feature is also mentioned in the :version text as one of +multi_byte, +multi_byte_ime or +multi_byte_ime/dyn If yes, check near the bottom of the :version text the name of the compiler: Vim binaries compiled with BCC32 have been notorious in the past for bad support of multi-byte characters, especially in filenames; IIUC, other compilers such as gcc and (don't remember the compiler executable name) MS Visual C have less problems in that respect. (I could be wrong though; I don't use non-Latin1 filenames and only very rarely non-7-bit-ASCII ones.) If has(multi_byte) is nonzero and it wasn't compiled with BCC32 then I don't know what it is -- maybe a bug. In this case, a makeshift workaround (until Bram fixes it) would be to rename the file back and forth to something with only 7-bit ASCII in the name. Normally, E303 means the swapfile can't be opened; but you should still be able to edit the file itself, unless it is very large. But you won't get a recovery option if Vim crashes, so don't forget to save your work extra often. Oh, and you are using a recent version of Vim aren't you? A year or two ago Vim just couldn't handle filenames with multibyte characters in them, but I thought that bug had been fixed. Best regards, Tony. Thanks for your answer, I use the vim 7.0 compiled with MS Visual C and it has multibyte. echo has(multi_byte) return 1. The file won't be opened and can't be edited even though the file is small. All what I get is an empty file. If I rename the file with ASCII, even with accented file name it will be opened. But notepad can open and edit it. Many thanks in advance, Andalou I now see the problem. You code page is not 936, right? Vim seems only able to open files with names that are valid in the current code page, as are many other applications that do not use the Unicode version of Windows APIs. This is an OS-related issue. You should not have such problems when the system locale uses UTF-8, such as modern Linux distros. -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: CVS service resumed?
On 5/12/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Edward Fox wrote: It seems that the CVS service of sourceforge.net resumed again. The host name changed to vim.cvs.sourceforge.net. So what? I tried it. Seems to work mostly, but it has forgotten my ssh key, need to type my password for every change and tag command... Perhaps it's a matter of waiting, the message mentions the new system comes up today. Just FYI. When I tried to update the CVS root in cvsmenu.vim, my SSH keys works for ezytools.cvs.sf.net (after retrieving the new host key). I used CVSNT, PuTTY, and pageant on Windows. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Any way to disable the capitalization check in spelling check?
Hi Bram and vimmers, I wonder if there is a way to disable the highlighting of word not capitalized? It does not reveal much useful info by :helpgrep [Cc]apitali[sz]. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: new logo
On 4/15/06, Benjamin Esham [EMAIL PROTECTED] wrote: On Apr 10, 2006, at 9:02 AM, Peter Slizik wrote: BTW, there is a trend towards more colorful, more playful icons. I dislike this trend, because most of those icons are much less legible than the icons having been replaced. Yes, that's true. Maybe adding some light glow, color transition, or shadow effects would help to make the logo more 'shiny'. But it depends on personal taste, of course. Personally, I *love* Matthew Webb's OS X versions of the Vim logo: http://www.cs.princeton.edu/~mtwebb/vim_icon/vim_icons.html Especially the matte version. It's the same design as the current logo, but without the im text and with some subtle gradients and brushed-metal effects. Does anyone think that it would be unreasonable to set this as the default icon for Mac OS X builds of Vim? It certainly blends better with the other apps' icons than the logo we have now (IMO). Cheers, -- Benjamin D. Esham [EMAIL PROTECTED] | http://bdesham.net | AIM: bdesham128 Wikipedia, the Free Encyclopedia • http://en.wikipedia.org Actually I use Matthew's icon in Yahoo! Widget's Zoomy Bar URL:http://widgets.yahoo.com/gallery/view.php?widget=38873. All the icon's there have the shiny look (and have no additional letters). However, I think it is one special incarnation of the Vim icon, and should not be regarded a universal solution. The real look depends on the look and feel of a specific OS (or distribution). If all the other icons are not shiny, a shiny Vim icon will look strange indeed. And there are more styles than being shiny (OSX-like) Best regards, -- Wu Yongwei URL: http://wyw.dcweb.cn/
