Re: why does :save not work with -stdin-
Hi Mohsin,
On 6/6/07, Mohsin [EMAIL PROTECTED] wrote:
I usually do search like this:
$ grep Word *.* | vim -u myvimrc -
$ cat myvimrc
:autocmd StdinReadPost * :sav! /tmp/x
but when I quit :q, vim always asks me to save the file again,
why is the file marked as modified?
I tried all combinations of flags, but can't get vim to
mark the file as saved,
It's a bug. Here is the patch. Please test it carefully, thanks very
much for reporting this to me. I'll ask Bram to add it to the official
release soon.
Index: buffer.c
===
--- buffer.c(revision 296)
+++ buffer.c(working copy)
@@ -171,14 +171,6 @@
/* Put the cursor on the first line. */
curwin-w_cursor.lnum = 1;
curwin-w_cursor.col = 0;
-#ifdef FEAT_AUTOCMD
-# ifdef FEAT_EVAL
- apply_autocmds_retval(EVENT_STDINREADPOST, NULL, NULL, FALSE,
- curbuf, retval);
-# else
- apply_autocmds(EVENT_STDINREADPOST, NULL, NULL, FALSE, curbuf);
-# endif
-#endif
}
}
@@ -207,6 +199,18 @@
unchanged(curbuf, FALSE);
save_file_ff(curbuf); /* keep this fileformat */
+#ifdef FEAT_AUTOCMD
+if (read_stdin)
+{
+# ifdef FEAT_EVAL
+apply_autocmds_retval(EVENT_STDINREADPOST, NULL, NULL, FALSE,
+ curbuf, retval);
+# else
+apply_autocmds(EVENT_STDINREADPOST, NULL, NULL, FALSE, curbuf);
+# endif
+}
+#endif
+
/* require ! to overwrite the file, because it wasn't read completely */
#ifdef FEAT_EVAL
if (aborting())
any insights appreciated,
mosh.
Regards,
Edward L. Fox
Re: 'fileencodings': Why use ucs-2le for cp936 file?
On 6/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, Recently I want to do some research about 'fileencodings', what I want is to recognize utf-8, ucs-2le, euc-cn and cp936 encodings. So I set the 'fencs' in my .vimrc: set fencs=ucs-bom,utf-8,ucs-2le,euc-cn,cp936 However, cp936 files are always recognized as ucs-2le and I got everything in a mess... If I remove the ucs-2le: set fencs=ucs-bom,utf-8,euc-cn,cp936 That would work, but ucs-2le files cannot get recognized at all. It is said that unicode files all have BOM, and obviously cp936 files do not have BOM, so I wonder why cp936 files get recognized as ucs-2le file without any BOM. It's not recommended using UCS-2 without BOM. It's not an easy thing to detect its file encoding automatically. Maybe you need a fenc detecting plugin, such as FencView. Although the current version of FencView cannot handle your problem, I think it will be able to do this after some modifications. Please contact Ming Bai [EMAIL PROTECTED] and tell him your problem. I tried to change my 'encoding' setting, but it doesn't affect anything. Any hints? -- Sincerely, Pan, Shi Zhu. ext: 2606 Regards, Edward L. Fox
Re: Tear off this menu in messages-history
To Yongwei:
Does this patch solve your problem?
To Bram:
Please consider adding this patch. I think it is really a bug.
Index: src/gui_w32.c
===
--- src/gui_w32.c (revision 296)
+++ src/gui_w32.c (working copy)
@@ -1051,7 +1051,7 @@
if (pMenu != NULL pMenu-strings[MENU_INDEX_TIP] != 0
GetMenuState(s_menuBar, pMenu-id, MF_BYCOMMAND) != -1)
{
- msg(pMenu-strings[MENU_INDEX_TIP]);
+ msg_outtrans(pMenu-strings[MENU_INDEX_TIP]);
setcursor();
out_flush();
did_menu_tip = TRUE;
Re: OT: Vi in a browser...
On 5/30/07, Tobias Klausmann [EMAIL PROTECTED] wrote: [...] as for the classic use case of wanting to edit textfields vim-style (longer blog posts come to mind), I usually use MozEx, an extension to FF, which allows to use any editor for such things. It has more features but I don't use any of them. Most of my Vimmers workmates recommend It's All Text! to me. So I just gave up MozEx before I had a try on it. A friend told me that he is developing a Firefox addon to emulate the Vi/Vim behaviors in all text areas in Firefox, without launching external applications. I'm looking forward to it. I can definitely recommend it. Especially considering the splendid UI of the ticket system I'm forced to use. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. Shalom, Edward L. Fox
Is it possible to do spelling check for comments only?
Hi VIMmers, When programming, I have to turn the spelling check off. Or it will show a lot of spelling mistakes in the code. I'd like to apply spelling check for sentences within the comment blocks only. Is it possible to configure VIM to do this? Best regards, Edward L. Fox
Re: Is it possible to do spelling check for comments only?
On 5/21/07, Swaroop C H [EMAIL PROTECTED] wrote: When programming, I have to turn the spelling check off. Or it will show a lot of spelling mistakes in the code. I'd like to apply spelling check for sentences within the comment blocks only. Is it possible to configure VIM to do this? See :help spell-syntax Hmmm, so that means that I could only define which regions to be spelling checked in the syntax highlight plugins. But I still do wish to have an option that could temporarily open spelling checking to the code regions without closing the syntax highlighting. Maybe I'll send a wish list to Bram. :-P Best, Swaroop --- www.ion.co.in Regards, Edward L. Fox
Re: Stable Vim version 7.1 has been released
I finally committed the two missing files from the sf.net's shell server. Let's blame the Great Fire Wall built by the P.R.C. government. On 5/13/07, Edward L. Fox [EMAIL PROTECTED] wrote: Hi Vimmers, On 5/13/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Announcing: Vim (Vi IMproved) version 7.1 This is a stable release of Vim, version 7.1. Since version 7.0 lots of problems were fixed and runtime files were updated. It has been one year and five days since 7.0! Most of Vim 7.1 was already available as patches for quite a while. A couple of test versions were made to spot problems in the distribution. Therefore Vim 7.1 can be considered very stable. If you are using an older version, it is highly recommended you install Vim 7.1. Several crashing bugs and a security issue were fixed. Once you have installed Vim 7.1 you can find details about the changes since Vim 7.0 with :help version-7.1. I will not make an Amiga or OS/2 binary for Vim 7.1. A Mac version is hopefully available soon on http://macvim.org/ Where to get it --- All files can be found below this directory: ftp://ftp.vim.org/pub/vim/ Information about which files to download for what system: http://www.vim.org/download.php A list of mirror sites can be found here: http://www.vim.org/mirrors.php Vim 7.1 is also available from CVS and Subversion: http://www.vim.org/cvs.php http://www.vim.org/subversion.php An overview of the files: UNIX: unix/vim-7.1.tar.bz2 sources + runtime files, bzip2 compressed VARIOUS: extra/vim-7.1-extra.tar.gz extra files extra/vim-7.1-lang.tar.gz multi-language files doc/vim71html.zip help files converted to HTML MS-WINDOWS: pc/gvim71.exe self-installing, includes all runtime files pc/vim71rt.zip runtime files for binaries below pc/vim71lang.zip files for translated messages and menus pc/gvim71.zip GUI binary for Windows 95/98/NT/2000/XP pc/gvim71ole.zip GUI binary with OLE support pc/gvim71_s.zipGUI binary for Windows 3.1 pc/vim71d16.zip16 bit console version for MS-DOS pc/vim71d32.zipconsole version for MS-DOS/Windows 95/98 pc/vim71w32.zipconsole version for Windows NT/2000/XP pc/vim71src.zipsources for PC (with CR-LF) DIFFS TO PREVIOUS RELEASE: unix/vim-7.0-7.1.diff.gzsources + runtime files extra/vim-7.0-7.1-extra.diff.gz extra files extra/vim-7.0-7.1-lang.diff.gz multi-language files unstable/unix/vim-7.1b-7.1.diff.gz sources + runtime files unstable/extra/vim-7.1b-7.1-extra.diff.gz extra files unstable/extra/vim-7.1b-7.1-lang.diff.gzmulti-language files Mailing lists - For user questions you can turn to the Vim mailing list. There are a lot of tips, scripts and solutions. You can ask your Vim questions, but only if you subscribe. See http://www.vim.org/maillist.php#vim If you want to help Vim development or get the latest patches, subscribe to the vim-dev mailing list. See http://www.vim.org/maillist.php#vim-dev Subject specific lists: Multi-byte issues: http://www.vim.org/maillist.php#vim-multibyte Macintosh issues: http://www.vim.org/maillist.php#vim-mac Before you ask a question you should search the archives, someone may already have given the answer. Reporting bugs -- Send them to [EMAIL PROTECTED]. Please describe the problem precisely. All the time spent on answering mail is subtracted from the time that is spent on improving Vim! Always give a reproducible example and try to find out which settings or other things influence the appearance of the bug. Try starting without your own vimrc file: vim -u NONE. Try different machines if possible. See :help bugs in Vim. Send me a patch if you can! If something needs discussing with other developers, send a message to the vim-dev mailing list. You need to subscribe first. Happy Vimming! -- hundred-and-one symptoms of being an internet addict: 114. You are counting items, you go 0,1,2,3,4,5,6,7,8,9,A,B,C,D /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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 tried three times but still was not able to commit the latest source into the subversion repository because of the internal error of sourceforge.net. Please wait patiently. I'll try to commit again when sourceforge.net's services recovered. [EMAIL PROTECTED] svn]$ svn ci SendingContents SendingMakefile SendingREADME.txt SendingREADME_ami.txt SendingREADME_amibin.txt
Re: Stable Vim version 7.1 has been released
On 5/14/07, David Nečas (Yeti) [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 09:28:11PM +0100, [EMAIL PROTECTED] wrote: Umm, I suspect there's still an issue for us pesky OSX users with our case-insensitive filesystems: [long list of successful updates snipped] svn: Failed to add file 'src/auto/config.h': object of the same name already exists Gah. Scrub that. Manually removing the file in question and updating again has sorted it (that's the first time I've had Subversion complain over several updates). Sorry for the noise... Actually, this is a repository bug. src/auto/config.h is fully generated therefore it should not be versioned. Yes, it's a bug. I can fix the problem, but not yet. Because I shall also need to delete the corresponding files in the CVS repository to keep the two repositories' consistency. If Bram would grant me such permission to delete these unnecessary files in the CVS and SVN repository, I'll do it right away. I already have the CVS writing privilege, so the only thing I need is just a permission. :-) Yeti -- http://gwyddion.net/ Cheers, Edward
Re: Stable Vim version 7.1 has been released
On 5/14/07, David Nečas (Yeti) [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 09:28:11PM +0100, [EMAIL PROTECTED] wrote: Umm, I suspect there's still an issue for us pesky OSX users with our case-insensitive filesystems: [long list of successful updates snipped] svn: Failed to add file 'src/auto/config.h': object of the same name already exists Gah. Scrub that. Manually removing the file in question and updating again has sorted it (that's the first time I've had Subversion complain over several updates). Sorry for the noise... Actually, this is a repository bug. src/auto/config.h is fully generated therefore it should not be versioned. Yes, it's a bug. I can fix the problem, but not yet. Because I shall also need to delete the corresponding files in the CVS repository to keep the two repositories' consistency. If Bram would grant me such permission to delete these unnecessary files in the CVS and SVN repository, I'll do it right away. I already have the CVS writing privilege, so the only thing I need is just a permission. :-) Yeti -- http://gwyddion.net/ Cheers, Edward
Re: Stable Vim version 7.1 has been released
runtime/doc/usr_44.txt Sendingruntime/doc/usr_45.txt Sendingruntime/doc/usr_90.txt Sendingruntime/doc/usr_toc.txt Sendingruntime/doc/various.txt Sendingruntime/doc/version4.txt Sendingruntime/doc/version5.txt Sendingruntime/doc/version6.txt Sendingruntime/doc/version7.txt Sendingruntime/doc/vi_diff.txt Sendingruntime/doc/visual.txt Sendingruntime/doc/windows.txt Sendingruntime/doc/workshop.txt Sendingruntime/ftplugin/ada.vim Sendingruntime/ftplugin/bst.vim Sendingruntime/ftplugin/cobol.vim Sendingruntime/ftplugin/eruby.vim Sendingruntime/ftplugin/ruby.vim Sendingruntime/indent/ada.vim Sendingruntime/indent/bst.vim Sendingruntime/indent/cobol.vim Sendingruntime/indent/eruby.vim Sendingruntime/indent/ruby.vim Sendingruntime/syntax/ada.vim Sendingruntime/syntax/aspvbs.vim Sendingruntime/syntax/bst.vim Sendingruntime/syntax/bzr.vim Sendingruntime/syntax/cobol.vim Sendingruntime/syntax/css.vim Sendingruntime/syntax/eruby.vim Sendingruntime/syntax/indent.vim Sendingruntime/syntax/initng.vim Sendingruntime/syntax/masm.vim Sendingruntime/syntax/mysql.vim Sendingruntime/syntax/rnoweb.vim Sendingruntime/syntax/ruby.vim Sendingruntime/syntax/vim.vim Sendingruntime/syntax/xdefaults.vim Sendingsrc/GvimExt/GvimExt.reg Sendingsrc/INSTALL Sendingsrc/Makefile Sendingsrc/auto/configure Sendingsrc/configure.in Sendingsrc/if_mzsch.c Sendingsrc/if_ruby.c Sendingsrc/mysign Sendingsrc/pty.c Sendingsrc/version.c Sendingsrc/version.h Sendingsrc/vim.def Sendingsrc/vim.h Sendingsrc/vim16.def Transmitting file data .svn: Commit failed (details follow): svn: PUT of '/svnroot/vim/!svn/wrk/2f7c20dc-6d81-4ddf-a12a-fc94c920dcf8/branches/vim7.1/src/if_mzsch.c': 500 Internal Server Error (https://vim.svn.sourceforge.net) svn: Your commit message was left in a temporary file: svn:'/src/vim7/svn/svn-commit.tmp' [EMAIL PROTECTED] svn]$ Regards, Edward L. Fox
Re: Stable Vim version 7.1 has been released
runtime/doc/usr_44.txt Sendingruntime/doc/usr_45.txt Sendingruntime/doc/usr_90.txt Sendingruntime/doc/usr_toc.txt Sendingruntime/doc/various.txt Sendingruntime/doc/version4.txt Sendingruntime/doc/version5.txt Sendingruntime/doc/version6.txt Sendingruntime/doc/version7.txt Sendingruntime/doc/vi_diff.txt Sendingruntime/doc/visual.txt Sendingruntime/doc/windows.txt Sendingruntime/doc/workshop.txt Sendingruntime/ftplugin/ada.vim Sendingruntime/ftplugin/bst.vim Sendingruntime/ftplugin/cobol.vim Sendingruntime/ftplugin/eruby.vim Sendingruntime/ftplugin/ruby.vim Sendingruntime/indent/ada.vim Sendingruntime/indent/bst.vim Sendingruntime/indent/cobol.vim Sendingruntime/indent/eruby.vim Sendingruntime/indent/ruby.vim Sendingruntime/syntax/ada.vim Sendingruntime/syntax/aspvbs.vim Sendingruntime/syntax/bst.vim Sendingruntime/syntax/bzr.vim Sendingruntime/syntax/cobol.vim Sendingruntime/syntax/css.vim Sendingruntime/syntax/eruby.vim Sendingruntime/syntax/indent.vim Sendingruntime/syntax/initng.vim Sendingruntime/syntax/masm.vim Sendingruntime/syntax/mysql.vim Sendingruntime/syntax/rnoweb.vim Sendingruntime/syntax/ruby.vim Sendingruntime/syntax/vim.vim Sendingruntime/syntax/xdefaults.vim Sendingsrc/GvimExt/GvimExt.reg Sendingsrc/INSTALL Sendingsrc/Makefile Sendingsrc/auto/configure Sendingsrc/configure.in Sendingsrc/if_mzsch.c Sendingsrc/if_ruby.c Sendingsrc/mysign Sendingsrc/pty.c Sendingsrc/version.c Sendingsrc/version.h Sendingsrc/vim.def Sendingsrc/vim.h Sendingsrc/vim16.def Transmitting file data .svn: Commit failed (details follow): svn: PUT of '/svnroot/vim/!svn/wrk/2f7c20dc-6d81-4ddf-a12a-fc94c920dcf8/branches/vim7.1/src/if_mzsch.c': 500 Internal Server Error (https://vim.svn.sourceforge.net) svn: Your commit message was left in a temporary file: svn:'/src/vim7/svn/svn-commit.tmp' [EMAIL PROTECTED] svn]$ Regards, Edward L. Fox
Re: WARNING! Don't update your local svn repository now!
On 5/12/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Nicolas Weber wrote: The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Can someone update http://www.vim.org/subversion.php to reflect these changes? I was still discussing what should actually be there, and making sure that SVN contains that. In my opinion vim7 should get you the latest stable version. So far that is 7.0.243, thus 7.0 with patches. As soon as Vim 7.1 is out of beta then vim7 should get you Vim 7.1. vim7.1 should get you the latest version of Vim 7.1. So far that is the beta version. After the release it will be the stable version, thus the same as vim7. Still need to check that it actually works this way. It's already this way. There might also be other ways to get one of these, but that is less relevant. In my opinion we should keep it easy for the downloader to select one of the available versions. The download page would only need one or two alternatives. I have never maintained a SVN repository, thus have no idea how difficult or easy these things are! I've found an easy way to solve that problem. So now can we can announce? -- In a world without walls and borders, who needs windows and gates? /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: WARNING! Don't update your local svn repository now!
On 5/12/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Nicolas Weber wrote: The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Can someone update http://www.vim.org/subversion.php to reflect these changes? I was still discussing what should actually be there, and making sure that SVN contains that. In my opinion vim7 should get you the latest stable version. So far that is 7.0.243, thus 7.0 with patches. As soon as Vim 7.1 is out of beta then vim7 should get you Vim 7.1. vim7.1 should get you the latest version of Vim 7.1. So far that is the beta version. After the release it will be the stable version, thus the same as vim7. Still need to check that it actually works this way. It's already this way. There might also be other ways to get one of these, but that is less relevant. In my opinion we should keep it easy for the downloader to select one of the available versions. The download page would only need one or two alternatives. I have never maintained a SVN repository, thus have no idea how difficult or easy these things are! I've found an easy way to solve that problem. So now can we can announce? -- In a world without walls and borders, who needs windows and gates? /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: [Announcement] Subversion repository location changed
On 5/10/07, Gautam Iyer [EMAIL PROTECTED] wrote: On Wed, May 09, 2007 at 02:20:52PM -0700, Micah Cowan wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? I got the same error. My response was rm -rf vim7 svn co https://svn.sourceforge.net/svnroot/vim/trunk vim7 svn switch can only switch from a directory into another directory inside the same repository. It doesn't allow the user to switch from one server to another server. So you will not be able to switch from svn.sourceforge.net to vim.svn.sourceforge.net. So you can try to switch to https://svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn.sourceforge.net sometimes gives out 403 forbidden errors when doing some maintaining work. The sf.net staff recommended to use vim.svn.sourceforge.net instead of svn.sourceforge.net. However, if you don't want to do any maintaining work, I think both URL will be OK. I've a question, though: isn't bleeding-edge development done in https://svn.sourceforge.net/svnroot/vim/trunk ? That /would/ be the appropriate line for the latest sources, right? I don't know. I'm still asking Bram for the latest sources. Currently, trunk and 7.1 branch will be the same. I hope so :) GI -- Top Ten New Intel Slogans For The Pentium: 6.831538 You Don't Need to Know What's Inside
Re: Compiling vim in mingw.
On 5/8/07, Markus Trenkwalder [EMAIL PROTECTED] wrote:
Tried the ftp versions (including patch 7.1a.001) now. Same again. And
as Edward Fox told earlier the SVN repository should be almost the same
as CVS.
*Almost* the same with ftp versions.
*Definitely* the same with CVS.
I also tried to find a better solution but as I could not find macro
that fits better I do also not know any alternative.
Regards
Markus
--
:wq \_ \_\_\_
\_\_ \_\_ \_\_ \_\_ \_\_
/(bb|[^b]{2})/ \_ \_ \_ \_\_\_\_\_\_ \_\_
Markus Trenkwalder \_ \_ \_\_ \_\_ \_\_
[EMAIL PROTECTED] \_ \_ \_\_ \_\_ \_\_
Fragen zu Vim? Kommen Sie zu mich, da werden Sie geholfen! :)
Re: Compiling vim in mingw.
On 5/8/07, Markus Trenkwalder [EMAIL PROTECTED] wrote:
Edward L. Fox wrote:
On 5/8/07, Markus Trenkwalder [EMAIL PROTECTED] wrote:
Tried the ftp versions (including patch 7.1a.001) now. Same again. And
as Edward Fox told earlier the SVN repository should be almost the same
as CVS.
*Almost* the same with ftp versions.
*Definitely* the same with CVS.
Exept the revisions ;)
Including revisions. I didn't set any keywords properties at any files
within svn repository. So svn will not update any revisions. :-)
To be honest I wanted to express that with my *almost*.
Regarts
Markus
--
:wq \_ \_\_\_
\_\_ \_\_ \_\_ \_\_ \_\_
/(bb|[^b]{2})/ \_ \_ \_ \_\_\_\_\_\_ \_\_
Markus Trenkwalder \_ \_ \_\_ \_\_ \_\_
[EMAIL PROTECTED] \_ \_ \_\_ \_\_ \_\_
Fragen zu Vim? Kommen Sie zu mich, da werden Sie geholfen! :)
[Announcement] Subversion repository location changed
Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Regards, Edward L. Fox
Could you please give me the most bleeding-edge sources?
Hi Bram, I noticed that you also maintained another CVS repository besides the sf.net's CVS repository. And many changes to that internal CVS won't be applied to the sf.net's CVS repository unless a large release is to be made. In my opinion, as the SVN repository is now standardized, could you please give me the most bleeding-edge sources so that I can commit them into the trunk/ directory of the SVN repository, and some users who wish to use the unstable experimental version then can help you to test the code. Best regards, Edward L. Fox
Re: WARNING! Don't update your local svn repository now!
On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: Hi Vimmers, As many many people requested, I finally decide to obey the svn book's advice and will build up trunk/ tags/ and branches/. But so far as you know, sf.net's svn service is not in a good status so I'm not able to commit all changes once. So I have to commit many times to build up this structure. So, PLEASE DON'T UPDATE YOUR LOCAL SVN REPOSITORY UNTIL THE WORK IS DONE. OR YOU WILL GET A CORRUPTED VERSION. Best regards, Edward L. Fox Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Regards, Edward L. Fox
Re: [Announcement] Subversion repository location changed
On 5/9/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Edward L. Fox announced: Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Shouldn't there be vim7.1a (the a'th candidate for 7.1) today, and eventually, when Bram releases version 7.1, vim7.1? So is the last argument to svn co correct? And isn't today's branch/trunk/whatever 7.1a rather than 7.1? 7.1, not 7.1a. Because as the alphabetical version changes so fast, personally I don't want to create too many branches for that. --Suresh
Re: surprised by beta
On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version Maybe you'll be surprised again today... Don't simply svn up. Take care~
WARNING! Don't update your local svn repository now!
Hi Vimmers, As many many people requested, I finally decide to obey the svn book's advice and will build up trunk/ tags/ and branches/. But so far as you know, sf.net's svn service is not in a good status so I'm not able to commit all changes once. So I have to commit many times to build up this structure. So, PLEASE DON'T UPDATE YOUR LOCAL SVN REPOSITORY UNTIL THE WORK IS DONE. OR YOU WILL GET A CORRUPTED VERSION. Best regards, Edward L. Fox
[Announcement] Subversion repository location changed
Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Regards, Edward L. Fox
Could you please give me the most bleeding-edge sources?
Hi Bram, I noticed that you also maintained another CVS repository besides the sf.net's CVS repository. And many changes to that internal CVS won't be applied to the sf.net's CVS repository unless a large release is to be made. In my opinion, as the SVN repository is now standardized, could you please give me the most bleeding-edge sources so that I can commit them into the trunk/ directory of the SVN repository, and some users who wish to use the unstable experimental version then can help you to test the code. Best regards, Edward L. Fox
Re: WARNING! Don't update your local svn repository now!
On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: Hi Vimmers, As many many people requested, I finally decide to obey the svn book's advice and will build up trunk/ tags/ and branches/. But so far as you know, sf.net's svn service is not in a good status so I'm not able to commit all changes once. So I have to commit many times to build up this structure. So, PLEASE DON'T UPDATE YOUR LOCAL SVN REPOSITORY UNTIL THE WORK IS DONE. OR YOU WILL GET A CORRUPTED VERSION. Best regards, Edward L. Fox Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Regards, Edward L. Fox
Re: [Announcement] Subversion repository location changed
On 5/9/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Edward L. Fox announced: Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Shouldn't there be vim7.1a (the a'th candidate for 7.1) today, and eventually, when Bram releases version 7.1, vim7.1? So is the last argument to svn co correct? And isn't today's branch/trunk/whatever 7.1a rather than 7.1? 7.1, not 7.1a. Because as the alphabetical version changes so fast, personally I don't want to create too many branches for that. --Suresh
Re: Compiling vim in mingw.
On 5/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Markus Trenkwalder wrote:
Hi list,
checked out vim-7.1a.001 today from svn (#263) and tried to compile it
with mingw-gcc and got the following error:
8
$ make -f Make_ming.mak
gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32
-DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -O3 -fomit-frame-pointer
-freg-struct-return -s gui_w32.c -o gobj/gui_w32.o
gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA'
gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'
make: *** [gobj/gui_w32.o] Error 1
8
My naive solution to this problem is:
8
--- src/gui_w32.c.000 Mon May 7 08:26:54 2007
+++ src/gui_w32.c Mon May 7 07:01:09 2007
@@ -232,7 +232,7 @@
LPARAM lParam;
} NMTTDISPINFO_NEW;
-#ifndef LPNMTTDISPINFO
+#if !defined(LPNMTTDISPINFO) !defined(TOOLTIPTEXTA)
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
8
Regards
Markus
You're not the first; there seems to have been a f*ckup in the svn commit
lately. I suggest you scrap your existing 7.1a sources and restart from
scratch, by downloading the 7.1a.000 sources then applying the 7.1a.001 patch.
Here are the files whose download I recommend:
1) the unpatched archives
http://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2
http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-extra.tar.gz
http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-lang.tar.gz
The first one is not a typo: even for Windows, I recommend the *Unix* + extra
+ lang sources. Together, they have exactly one copy of every source file
needed to compile Vim for *any* platform including Windows.
Unpack them on top of each other at what will become your Vim directory for
compiling, maybe something like D:\build\vim : they will create a subfolder
vim71a and place all the sources in it, creating subfolders as needed.
I don't know if you have a bz2 decompresser program, or if your version of
patch will accept the patch format. In both cases, MinGW may or may not
offer the necessary packages (look there first) but I know Cygwin does. (Even
WinZip knows about the .tar and .gz formats.)
2) the patch
http://ftp.vim.org/pub/vim/unstable/patches/7.1a/7.1a.001
Download it (and optionally its sibling files README MD5 and MD5SUMS) into a
newly-created subfolder named (in my example) D:\build\vim\vim71a\patches then
apply it by using (IIUC)
D:
cd \build\vim\vim70
patch -p0 patches\7.1a.001
Could you please tell me the differences between svn repository and
your downloaded and patched sources? In fact #262 is a broken
committing because the patch 7.1a.001 was applied to 7.0.243, so the
svn sources are broken. But #263 is just synced from the cvs
repository. So if it is broken, so is cvs.
See details at http://users.skynet.be/antoine.mechelynck/vim/compile.htm but
replace everywhere the directory name .../vim70/... by .../vim71a/..., even in
the name of what will become your production 7.1a $VIMRUNTIME after
compiling and installing.
I used Cygwin gcc and Make_cyg.mak but using MingGW and Make_ming.mak is not
very different. I trust you will know what to change in the procedure to cater
for any differences between them.
Best regards,
Tony.
--
All snakes who wish to remain in Ireland will please raise their right
hands.
-- Saint Patrick
Re: Vim version 7.1a BETA -- runtime files ?
On 5/8/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Yakov Lerner wrote: On 5/5/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA I compared runtime files form ftp [1] and from svn [2]. Both vims are labeled vim71a. But many runtimes are different. In svn, many files are labeled 2007. In ftp, they are 2006 versions. Why this difference in runtimes ? Yakov [1] ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2 [2] https://svn.sourceforge.net/svnroot/vim/vim7 Do I need to hunt down the differences? Please give a specific example. What label are you talking about? At closer examination, differences turned out to be in $Id..$, $Revision..$ $Date...$ lines only, except for one file which has read differences: These tags are automatically updated when the files are committed into the cvs repository. So it's very normal that the cvs versions are different from Bram's local versions. runtime/autoload/spellfile.vim -- see diffs below. By labels I meant the cvs $Id...$ keywords and other $..$ keywords. Full diffs are attached. Diffs are produced by the script diff-vim-ftp-svn.sh, also attached. diff -r --exclude=.svn /var/tmp/vim-untar/vim71a/runtime/autoload/spellfile.vim /var/tmp/vim-svn/vim7/runtime/autoload/spellfile.vim 3c3 Last Change:2006 Aug 29 --- Last Change:2007 May 06 60a61 Remember the buffer number, we check it below. 61a63 let newbufnr = winbufnr(0) 67c69,88 g/^/d --- Careful: Nread() may have opened a new window for the error message, we need to go back to our own buffer and window. if newbufnr != winbufnr(0) let winnr = bufwinnr(newbufnr) if winnr == -1 Our buffer has vanished!? Open a new window. echomsg download buffer disappeared, opening a new one new setlocal bin else exe winnr . wincmd w endif endif if newbufnr == winbufnr(0) We are back the old buffer, remove any (half-finished) download. g/^/d else let newbufnr = winbufnr(0) endif 73c94 bwipe! --- exe newbufnr . bwipe! 99,101c120 if getline(2) !~ 'VIMsug' echo 'Sorry, downloading failed' else --- if getline(2) =~ 'VIMsug' 103a123,136 set nomod else echo 'Sorry, downloading failed' Go back to our own buffer/window, Nread() may have taken us to another window. if newbufnr != winbufnr(0) let winnr = bufwinnr(newbufnr) if winnr != -1 exe winnr . wincmd w endif endif if newbufnr == winbufnr(0) set nomod endif 105d137 set nomod 109c141,142 bwipe --- Wipe out the buffer we used. exe newbufnr . bwipe The svn version is the same with the cvs version. And it seems that the svn version is much newer than the ftp version. Regards, E.L.Fox
Re: surprised by beta
On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version No, there won't be any tags, branches here, every thing is just going linearly, giggling.
Re: Compiling vim in mingw.
On 5/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Markus Trenkwalder wrote:
Hi list,
checked out vim-7.1a.001 today from svn (#263) and tried to compile it
with mingw-gcc and got the following error:
8
$ make -f Make_ming.mak
gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32
-DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME
-DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -O3 -fomit-frame-pointer
-freg-struct-return -s gui_w32.c -o gobj/gui_w32.o
gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA'
gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'
make: *** [gobj/gui_w32.o] Error 1
8
My naive solution to this problem is:
8
--- src/gui_w32.c.000 Mon May 7 08:26:54 2007
+++ src/gui_w32.c Mon May 7 07:01:09 2007
@@ -232,7 +232,7 @@
LPARAM lParam;
} NMTTDISPINFO_NEW;
-#ifndef LPNMTTDISPINFO
+#if !defined(LPNMTTDISPINFO) !defined(TOOLTIPTEXTA)
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
8
Regards
Markus
You're not the first; there seems to have been a f*ckup in the svn commit
lately. I suggest you scrap your existing 7.1a sources and restart from
scratch, by downloading the 7.1a.000 sources then applying the 7.1a.001 patch.
Here are the files whose download I recommend:
Well, well, well... It seems that the svn repository is nearly the
same with the manually downloaded tarballs...
Here is the diff:
diff --exclude=.svn -r vim71a/Filelist svn/Filelist
571c571,572
runtime/icons \
---
runtime/icons/README.txt \
runtime/icons/*.info \
647c648,649
farsi \
---
farsi/README.txt \
farsi/fonts/*/far* \
Only in vim71a/farsi: CVS
diff --exclude=.svn -r vim71a/runtime/autoload/ada.vim
svn/runtime/autoload/ada.vim
4c4
$Id: ada.vim 448 2006-11-05 14:53:19Z krischik $
---
$Id: ada.vim,v 1.2 2007/05/06 13:38:48 vimboss Exp $
7,8c7,8
$Author: krischik $
$Date: 2006-11-05 15:53:19 +0100 (Sun, 05 Nov 2006) $
---
$Author: vimboss $
$Date: 2007/05/06 13:38:48 $
10c10
$Revision: 448 $
---
$Revision: 1.2 $
diff --exclude=.svn -r vim71a/runtime/autoload/adacomplete.vim
svn/runtime/autoload/adacomplete.vim
4c4
$Id: adacomplete.vim 448 2006-11-05 14:53:19Z krischik $
---
$Id: adacomplete.vim,v 1.2 2007/05/06 12:44:46 vimboss Exp $
6,7c6,7
$Author: krischik $
$Date: 2006-11-05 15:53:19 +0100 (Sun, 05 Nov 2006) $
---
$Author: vimboss $
$Date: 2007/05/06 12:44:46 $
9c9
$Revision: 448 $
---
$Revision: 1.2 $
diff --exclude=.svn -r vim71a/runtime/autoload/decada.vim
svn/runtime/autoload/decada.vim
4c4
$Id: decada.vim 448 2006-11-05 14:53:19Z krischik $
---
$Id: decada.vim,v 1.2 2007/05/06 12:26:20 vimboss Exp $
7,8c7,8
$Author: krischik $
$Date: 2006-11-05 15:53:19 +0100 (Sun, 05 Nov 2006) $
---
$Author: vimboss $
$Date: 2007/05/06 12:26:20 $
10c10
$Revision: 448 $
---
$Revision: 1.2 $
diff --exclude=.svn -r vim71a/runtime/autoload/gnat.vim
svn/runtime/autoload/gnat.vim
4c4
$Id: gnat.vim 448 2006-11-05 14:53:19Z krischik $
---
$Id: gnat.vim,v 1.2 2007/05/06 14:13:49 vimboss Exp $
7,8c7,8
$Author: krischik $
$Date: 2006-11-05 15:53:19 +0100 (Sun, 05 Nov 2006) $
---
$Author: vimboss $
$Date: 2007/05/06 14:13:49 $
10c10
$Revision: 448 $
---
$Revision: 1.2 $
diff --exclude=.svn -r vim71a/runtime/autoload/rubycomplete.vim
svn/runtime/autoload/rubycomplete.vim
4c4
Info: $Id: rubycomplete.vim,v 1.39 2006/12/13
21:20:47 segy Exp $
---
Info: $Id: rubycomplete.vim,v 1.7 2007/05/06 12:07:59 vimboss
Exp $
diff --exclude=.svn -r vim71a/runtime/compiler/decada.vim
svn/runtime/compiler/decada.vim
4c4
$Id: decada.vim 429 2006-10-15 17:43:45Z krischik $
---
$Id: decada.vim,v 1.2 2007/05/06 13:56:27 vimboss Exp $
7,8c7,8
$Author: krischik $
$Date: 2006-10-15 19:43:45 +0200 (So, 15 Okt 2006) $
---
$Author: vimboss $
$Date: 2007/05/06 13:56:27 $
10c10
$Revision: 429 $
---
$Revision: 1.2 $
diff --exclude=.svn -r vim71a/runtime/compiler/gnat.vim
svn/runtime/compiler/gnat.vim
4c4
$Id: gnat.vim 448 2006-11-05 14:53:19Z krischik $
---
$Id: gnat.vim,v 1.2 2007/05/06 13:43:09 vimboss Exp $
7,8c7,8
$Author: krischik $
$Date: 2006-11-05 15:53:19 +0100 (Sun, 05 Nov 2006) $
---
$Author: vimboss $
$Date: 2007/05/06 13:43:09 $
10c10
$Revision: 448 $
---
$Revision: 1.2 $
Only in svn/runtime/doc: getscript.txt
diff --exclude=.svn -r vim71a/runtime/ftplugin/ada.vim
Re: Compiling vim in mingw.
On 5/8/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Edward L. Fox wrote: On 5/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: [...] You're not the first; there seems to have been a f*ckup in the svn commit lately. I suggest you scrap your existing 7.1a sources and restart from scratch, by downloading the 7.1a.000 sources then applying the 7.1a.001 patch. Here are the files whose download I recommend: 1) the unpatched archives http://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2 http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-extra.tar.gz http://ftp.vim.org/pub/vim/unstable/extra/vim-7.1a-lang.tar.gz The first one is not a typo: even for Windows, I recommend the *Unix* + extra + lang sources. Together, they have exactly one copy of every source file needed to compile Vim for *any* platform including Windows. Unpack them on top of each other at what will become your Vim directory for compiling, maybe something like D:\build\vim : they will create a subfolder vim71a and place all the sources in it, creating subfolders as needed. I don't know if you have a bz2 decompresser program, or if your version of patch will accept the patch format. In both cases, MinGW may or may not offer the necessary packages (look there first) but I know Cygwin does. (Even WinZip knows about the .tar and .gz formats.) 2) the patch http://ftp.vim.org/pub/vim/unstable/patches/7.1a/7.1a.001 Download it (and optionally its sibling files README MD5 and MD5SUMS) into a newly-created subfolder named (in my example) D:\build\vim\vim71a\patches then apply it by using (IIUC) D: cd \build\vim\vim70 patch -p0 patches\7.1a.001 Could you please tell me the differences between svn repository and your downloaded and patched sources? In fact #262 is a broken committing because the patch 7.1a.001 was applied to 7.0.243, so the svn sources are broken. But #263 is just synced from the cvs repository. So if it is broken, so is cvs. See details at http://users.skynet.be/antoine.mechelynck/vim/compile.htm but replace everywhere the directory name .../vim70/... by .../vim71a/..., even in the name of what will become your production 7.1a $VIMRUNTIME after compiling and installing. [...] My downloaded and patched sources (from the ftp repository, thus bypassing both cvs and svn) are Bram's official 7.1a.000 full sources and Bram's official 7.1a.001 patch. If (as you're saying) the svn repository mistakenly applied the 7.1a.001 patch against the 7.0.243 sources, by doing as I suggest you won't make that error. And I don't know whether or not the CVS repository is broken, but AFAIK the FTP uploads are made directly under Bram's own responsibility, and IIUC those aren't broken (but they're incremental: you got to apply the patches yourself). I've already downloaded the ftp version and applied the patch. And in my previous post I gave out the diff information between the ftp version and the svn version. In fact nearly every file is the same except the cvs version tags. spellfile.vim is different but the svn version is much more fresh. And ftp version even has some unused folders and files such as CVS directory. So... I don't think I need to commit my patched ftp version into svn repository. Any suggestions? Best regards, Tony. -- If you give Congress a chance to vote on both sides of an issue, it will always do it. -- Les Aspin, D., Wisconsin
Fwd: problem with win32 vim 7.1a.001
-- Forwarded message -- From: Edward L. Fox [EMAIL PROTECTED] Date: May 7, 2007 2:22 PM Subject: Re: problem with win32 vim 7.1a.001 To: Michael Wookey [EMAIL PROTECTED] On 5/7/07, Michael Wookey [EMAIL PROTECTED] wrote: Hello vim list, I've just synced up to 7.1a.001 (svn #263) and built on Win32 (MSVC). Everything builds fine and I replace my previous gvim.exe and vim.exe with the newly built versions. I also sync my runtime from ftp.nluug.nl. My vim installation is in: C:\Vim\vim70 My config is in: C:\Vim\_vimrc Additional plugins are in: C:\Vim\vimfiles\... This has always worked fine as this is the structure set up by the vim win32 installer. I now find that launching gvim/vim doesn't find my _vimrc or my vimfiles runtime. I can get it to load my _vimrc by moving it to: C:\Vim\Vim70\_vimrc However my runtime isn't picked up as :scriptnames doesn't list any plugins loaded. Is it just me or has something broken win32 vim? My previous sync was svn#254 (Vim 7.0.236) with a runtime sync from the same time and everything was fine. Any ideas? Maybe you can rename all your directories named Vim70 to Vim71a. Best regards, Edward
Re: Vim version 7.1a BETA -- svn ?
On 5/7/07, François Pinard [EMAIL PROTECTED] wrote: [Martin Krischik] [Martin Krischik] That is probalby because the svn server is a mess. [probably] Only the vim svn archive has no space for tags, braches or releases. [branches] It is not a mess, merely being different. If there is ever a _real_ need for another organisation of the Subversion repository for Vim, we can be fairly confident that it will be addressed. But now, the Subversion repository mirrors a non-Subversion one, this is for users convenience, and that's very nice already. Bram currently does not use Subversion for Vim development, so there is no point pretending that he does. If Bram was using Subversion, he might feel like changing things. But even then, the needs would mainly be Bram's! Well, currently the svn repository has no tags, branches and trunk, unlike most of the other svn repositories. But that's not because it's a mirror of a non-svn repository - cvs can also uses tags and branches. The main reason is, Bram doesn't use cvs for development, either. He maintains another repository internally. So both cvs and svn are doing the same thing as an ftp server. But you can do valuable service and still do it wrong [...] Once again, being different does not imply being wrong. We should not be overly dogmatic in such matters. If the download recipes are clear and work as expected, the repository fills its role. Yes. If once needed, we can create the needed trunk, branches, tags directories very simply with just a few commands. So just don't panic. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Vim version 7.1a BETA -- svn ?
On 5/7/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: François Pinard wrote: [Martin Krischik] [Martin Krischik] That is probalby because the svn server is a mess. [probably] Only the vim svn archive has no space for tags, braches or releases. [branches] It is not a mess, merely being different. If there is ever a _real_ need for another organisation of the Subversion repository for Vim, we can be fairly confident that it will be addressed. But now, the Subversion repository mirrors a non-Subversion one, this is for users convenience, and that's very nice already. Bram currently does not use Subversion for Vim development, so there is no point pretending that he does. If Bram was using Subversion, he might feel like changing things. But even then, the needs would mainly be Bram's! But you can do valuable service and still do it wrong [...] Once again, being different does not imply being wrong. We should not be overly dogmatic in such matters. If the download recipes are clear and work as expected, the repository fills its role. Anyway, if the code mirrored on that svn server belongs only to the 7.0 (release) code tree, there are no branches, since every patchlevel comes linearly on top on the one before, and there is one set of files applicable to all platforms and featuresets. _If_ there comes a 7.0.244, _and_ it branches out from 7.0.243 away from 7.1a.000 and 7.1a.001, _and_ both 7.0 and 7.1a are further mirrored on svn, _then_ there will maybe be a reason to define a branch point. But not before. Bram won't make such branches. He always commit patches linearly. If he one day can finally realize that how valuable the branches are, we'll create the tags and branches directories in the svn directory right away. It only costs a few commands. :-) Best regards, Tony. -- Speer's 1st Law of Proofreading: The visibility of an error is inversely proportional to the number of times you have looked at it.
Re: Vim version 7.1a BETA -- svn ?
On 5/6/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 5/6/07, Martin Krischik [EMAIL PROTECTED] wrote: Am Sonntag 06 Mai 2007 schrieb Yakov Lerner: On 2007-05-05, Bram Moolenaar [EMAIL PROTECTED] wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA I tried to build vim7.1 from svn. But all I get from usual svn location (https://svn.sourceforge.net/svnroot/vim/vim7), is vim 7.0.236. Will vim7.1 be served at this localtion eventually ? That is probalby because the svn server is a mess. I have to disagree. The svn maintainer does valuable service to the community. The svn service is really stable, unlike the cvs server. I'd like to really thank the svn updater for keeping the svn updated. The reason why updates did not make it to svn was that cvs server was down, as Bram explained above. I don't think so. I guess the reason why updates did not make it to svn was that the svn committer was out for holiday. Because the svn committing work has nothing to do with the cvs service. It only depends on the ftp service: the committer checks out the patches from the ftp, not from cvs. Yakov
Re: vim 7.1?
On 4/27/07, Jonathan Smith [EMAIL PROTECTED] wrote: A.J.Mechelynck wrote: - Insane? All is relative. We're only at 7.0.233 as of today. FYI, Vim 6.2 went to 532 patches, see http://ftp.vim.org/pub/vim/patches/ Release early, release often :) Yes, I admit that you are right. But unfortunately Vim is not developing in Bazaar's way, at least not that way currently. Vim has a very very large TODO list here: ftp://ftp.vim.org/pub/vim/runtime/doc/todo.txt I sometimes guess it would be nice to import the todo list into some tracking system such as trac, and then a lot of *submitters* could participate into the development concurrently. But sadly, most of us are not able to understand Vim's source code as clearly as Bram. I also submitted some dirty patches and Bram had to correct many mistakes for me. So there can't be more *submitters* until some of us could spend as much time as Bram. - What devel tree? I'll believe that a 7.1 is on the rails when I see at least an alpha. Before that, AFA-anyone-CT, there's no devel tree. Let's not presume about what we know nothing about. Hence presume. If you had browsed the svn repository, you'll discovered that there are no trunk, branches, tags directories. So... You know what I mean... - It's not anyone, it's Bram Moolenaar and no-one else; and since he now has a full-time job again, it's a small sort of miracle that he still finds some time for Vim. Even if BM is the only one who can actually make a release, I'd imagine others have opinions on the matter. Anyway, I was just wondering. That's why Yzis branched out from Vim project. And then, they played so badly... -smithj
Re: suggestion
On 4/18/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: David Howland wrote: Dear Vim gods, Please consider adding the following command to Vim: :bc (for buffer close) It acts just like :bd , except that if the buffer is in a split window, it does not remove the window. Thank you. Sincerely, dave You mean if the buffer is displayed it would do nothing? I think he meant that the (:bc)ed buffer should be removed, and a new *untitled* buffer should be opened in the position of the previous buffer. So the windows layout would not be changed. Best regards, Tony. -- You will lose your present job and have to become a door to door mayonnaise salesman.
Re: GB18030 != CP936
Hi all,
On 3/1/07, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram,
On 3/1/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
Yongwei Wu wrote:
My main point is that if our purpose is to make Vim novices edit
Simplified Chinese files (almost always encoded in GBK) without
troubles in the zh_CN.GB18030 environment, a hack to set encoding to
CP936 will be enough for all practical purposes. Vim veterans will
know how to have their way around. My objection to Patch 58 is only
that it *disabled* Vim veteran's possibility to edit GB18030 files.
So basically you want to set 'encoding' to cp936, but not use the
alias. So that most files can be edited without trouble, and conversion
still works for people who need the extra characters. Thus instead of
falling back to utf-8 in set_init_1() you would fall back to cp936.
Then no other options need to be set (hopefully).
Try this patch:
*** ../../vim-7.0.205/src/option.c Tue Oct 17 18:36:03 2006
--- option.cWed Feb 28 21:52:39 2007
***
*** 3290,3295
--- 3290,3303
* If not, go back to the default latin1. */
save_enc = p_enc;
p_enc = p;
+ if (STRCMP(p_enc, gb18030) == 0)
+ {
+ /* We don't support gb18030, but cp936 is 99% the same, thus
+* use that. It's not an alias to still support conversion
+* between gb18030 and utf-8. */
+ p_enc = vim_strsave((char_u *)cp936);
+ vim_free(p);
+ }
if (mb_init() == NULL)
{
opt_idx = findoption((char_u *)encoding);
*** ../../vim-7.0.205/src/mbyte.c Tue Dec 5 22:09:02 2006
--- mbyte.c Tue Feb 27 16:27:44 2007
***
*** 364,370
{949, IDX_CP949},
{936, IDX_CP936},
{gbk, IDX_CP936},
- {gb18030, IDX_CP936}, /* only 99% the same */
{950, IDX_CP950},
{eucjp, IDX_EUC_JP},
{unix-jis, IDX_EUC_JP},
--- 364,369
Thanks, it works for me. (Hi Edward, would you please test whether it
works for you?)
It seems that everything goes well. Then we could release this patch soon. :-)
Sorry for bother you so much with my previous messy work. :-P
One minor comment: is 99% the same is very vague (it is far from
true if we count the coding points). I would phrase something like:
/* We don't support gb18030, but cp936 is a good substitute
* for many practical purposes, thus use that. It's not an
* alias to still support conversion between gb18030 and utf-8.
*/
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
Regards,
Edward
Re: GB18030 != CP936
Hi all,
On 2/26/07, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram,
On 2/26/07, Yongwei Wu [EMAIL PROTECTED] wrote:
Hi Bram,
My test shows when I use ++enc to open a file in GB18030, Vim uses
CP936, which is not correct. GB18030 is a 1, 2, or 4 byte encoding,
while CP936 is a 1 or 2 byte encoding. The iconv on my system works
correctly.
I test with gVim 7.0.201 on Windows XP.
The problem is in Patch 58:
+ {gbk, IDX_CP936},
+ {gb18030, IDX_CP936}, /* only 99% the same */
I made the patch. And I knew that GB18030 and GBK is not the same.
Actually it's easy to support GB18030 well. And in most of the cases,
few people use the characters included in GB18030 and excluded in GBK.
So I suggest that these people could use UTF-8 to edit the files and
convert the file to GB18030 later on.
If anybody can offer a patch that makes vim support GB18030 perfectly,
it is highly appreciated.
If somebody specifically says a file is in GB18030, it is NOT GBK then.
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
Regards,
Edward L. Fox
Re: GB18030 != CP936
Hi Vimmers,
On 2/26/07, Yongwei Wu [EMAIL PROTECTED] wrote:
On 2/26/07, Edward L. Fox [EMAIL PROTECTED] wrote:
Hi Wu,
On 2/26/07, Yongwei Wu [EMAIL PROTECTED] wrote:
On 2/26/07, Edward L. Fox [EMAIL PROTECTED] wrote:
Hi all,
The problem is in Patch 58:
+ {gbk, IDX_CP936},
+ {gb18030, IDX_CP936}, /* only 99% the same */
I made the patch. And I knew that GB18030 and GBK is not the same.
Actually it's easy to support GB18030 well. And in most of the cases,
few people use the characters included in GB18030 and excluded in GBK.
So I suggest that these people could use UTF-8 to edit the files and
convert the file to GB18030 later on.
If anybody can offer a patch that makes vim support GB18030 perfectly,
it is highly appreciated.
It is not needed. With libiconv GB18030 files can be processed in Vim.
I commented out that line, tested it, and it was OK.
I don't have any compiler now so I'm not able to reproduce your
modifications currently. But I still remember that before this patch,
gvim was not able to handle GBK/GB18030 encodings. The menu bar and
toolbar's captions were all malformed if you were using GBK or GB18030
encoding. You can find this tip in many Chinese vim-related websites:
Fixing the malformed characters in the menu bar and toolbar.
set encoding=cp936
so $VIMRUNTIME/delmenu.vim
so $VIMRUNTIME/menu.vim
Maybe you are using utf-8 as your editing encoding and use iconv to
convert the text into GB18030 when you save your file.
Yes.
Could you also
have a test using GB18030 as encoding when editing the file?
I believe it won't work. GB18030 is not something Vim claims to
support natively, and I do not think it needs to be :-).
So I recommended that we keep this patch which alias GB18030 to GBK.
Although it's not correct indeed, few people use the characters
outside GBK and most of the people will be happy that gvim can deal
with 99% of the GB18030 characters correctly. As you see, many
distributions like RHEL uses GB18030 as the default Chinese encoding
and gvim doesn't work with the default settings under these systems.
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
Any further suggestions are welcome.
Yours,
Edward Leap Fox
Re: GB18030 != CP936 (Alternative project?)
Hi Tony, On 2/27/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: [...] Here is an alternative way to handle it, which may be the right way from a conceptual point of view, and in the long term, though it may be much more difficult from the coding point of view. It may or may not be the right thing to do pragmatically: Treat GB18030 as what it is, namely, a Unicode Transformation Format. In other words, whenever 'encoding' is set to GB18030, use UTF-8 internally and convert when reading and writing, just like we already do for UTF-16le, UTF-16be, UTF-32le and UTF-32be. There is still another problem. When using gvim under Windoze with CP936 locale, we can only set the encoding to CP936. Or the messages in gvim will become malformed characters. Could anybody offer a good solution to this problem? This, of course, also suffers from the performance problems related to conversion GB18030 = UTF-8. Best regards, Tony. -- Love and scandal are the best sweeteners of tea. Regards, Edward Leap Fox
Re: 2html.vim 256 color support
Hi Calmar, On 2/24/07, calmar [EMAIL PROTECTED] wrote: Hi all, I setup 2html.com for supporting 256 colors as well http://www.calmar.ws/tmp/2html.vim I rather guessed on the grey colors 232-255 the colors 16 - 231 seem to be ok, at least it follows some logic. Even so, I don't think 16 should be black or should it? Maybe someone wants to tweak that some further and update the 2html.vim then? Anyway, Cheers marco -- (o_ It rocks: LINUX + Command-Line-Interface //\ V_/_ http://www.calmar.ws I'm not able to access your web pages. Could you please send me the patch as attachment? Best regards, Edward Leap Fox
Overflow when striking Ctrl-a on a large number
Hi Vimmers, If you strike Ctrl-a in normal mode on 12345678912, you will get 3755744321. Obviously an integer overflow happens here. Do you think it's necessary to add large decimal related algorithm into Vim to solve this kind of problems? Or at least we should give out an error message... Regards, Edward Leap Fox
Re: Overflow when striking Ctrl-a on a large number
On 12/4/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Edward L. Fox wrote: If you strike Ctrl-a in normal mode on 12345678912, you will get 3755744321. Obviously an integer overflow happens here. Do you think it's necessary to add large decimal related algorithm into Vim to solve this kind of problems? Or at least we should give out an error message... Or compile Vim with 64 bit ints. I'm not sure it is worth adding code for big numbers, they are hardly ever used. Vim also doesn't support floating point. One has to stop somewhere. After all this is a text editor, not a spreadsheet. In fact I don't think it is worth adding the code, either. But I think it is necessary to add code for showing an error message when overflow occurs. -- Q: How many hardware engineers does it take to change a lightbulb? A: None. We'll fix it in software. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: Patch 7.0.167
Hi Bram, On 11/22/06, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] I didn't forget it, I just had to go away while waiting for the previous version to be tagged. Tagging all the files for a specific version is quite slow, it's currently the main bottleneck in sending out patched versions. So... Why not just commit the code to the CVS repository without tagging them? It's much faster. When you need to check out a specific version, just use subversion. It is much faster and more convenient. Regards, Eddy
Re: Convert2HTML Again
Hi developers,
On 9/22/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
Edd -
I have spoken to your development team and I think we have come to a
conclusion.
I draw your attention to this thread:
http://tech.groups.yahoo.com/group/vimdev/message/44853
Lemme know your opinions.
I haven't heard from people who have actually made changes to this
script in the past. Most remarks I have seen are I think..., which
isn't definitive.
I still don't know why the p /p was there. There must have been a
reason, it didn't get there by accicent. I last talked about this with
Edward Fox, let me copy this message to him. Edward, what is your opinion
about this patch?
This script works perfectly. Edd Barrett also solved another problem
made by the previous maintainer that the leading space doesn't appear
under xhtml mode, which I didn't solved last time I modified this
script. Thanks Edd!
But we should change one thing before we include this patch into the
official version. In the patch file, line 97:
+execute normal! A\npre { font-family: courier; color: . s:fgc
. ; background-color: . s:bgc . ; }\e
Should be:
+execute normal! A\npre { font-family: Courier, monospace; color:
. s:fgc . ; background-color: . s:bgc . ; }\e
As W3C suggested, every font-family indication must finish with a
*GENERIC* font family name, possible values are serif, sans-serif
or monospace. So I added monospace here.
- Bram
--
Zen Microsystems: we're the om in .com
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Best regards,
Edward L. Fox
Re: UTF-8 Problem with Localization in Windows GVIM
On 8/20/06, Yongwei Wu [EMAIL PROTECTED] wrote: This is really an old problem. It begins with VIM 6. While it is possible to set encoding=UTF-8 on Windows to be able to process text file in multiple encodings at the same time, the localized menu/messages has problems. The simplest _vimrc one may think of will render anything except the menu incorrect: set encoding=utf-8 source $VIMRUNTIME/vimrc_example.vim Reverse the order of these two lines will make the tool tips of the toolbar buttons correct, but the menu will be corrupt, as well as all the localized messages. The best I can get is with this _vimrc (simplified): source $VIMRUNTIME/vimrc_example.vim set encoding=utf-8 lang messages zh_CN.UTF-8 runtime! delmenu.vim In the time of Vim 6, it works well, except the tool tips for the toolbar buttons. I have to disable the toolbar translations in menu_zh_cn.utf-8.vim to make it work perfectly. With the new tab support in Vim 7, more headaches come. When I use localized messages, the context menu on the tabs (Close tab, New tab, and Open tab ...) is corrupt and the text is unreadable. Since the translation seems not in a .vim file, I find nowhere to fix it. Editing vim.mo might work, but it seems too incovenient and unreliable. The problem, as it seems to me, is that the context menu on the tab and the tool tips for the toolbar buttons only support the `ANSI' encoding. Any fixes/hacks to make it work? I knew that. I'll debug it soon. Before I hack out this problem, you can still do some blaming work to Micro$oft for its *so wonderful* multilinguagiation mechanics. I'm sorry but I'm not going to work out this problem for Vim6. So you'll have to upgrade to Vim7 even if I could solve the problem... Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ Regards, Edward L. Fox
Re: Why is after/colors/colorscheme.vim disabled?
On 8/21/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: Peter Hodge wrote: Hello, I am just curious as to why after/colors/ scripts are disabled instead of behaving like after/ftplugin and after/syntax scripts? regards, Peter I'm not sure if it's a bug or a feature, but Every bug is a feature. :-) :colorscheme foobar works like :runtime colors/foobar.vim with no exclamation mark after :runtime. To use ~/.vim/colors/foobar.vim as a user addition to $VIMRUNTIME/colors/foobar.vim, invoke it with :runtime! colors/foobar.vim (with exclamation mark) instead. You might even want to define a user-command :command ColorScheme -nargs=1 runtime! colors/args.vim See :help :runtime Best regards, Tony.
Temporary solution (was: Malformed character ...)
Hi Bram, As the problem is caused by iconv and we won't be able to fix the problem soon, and this problem influences gb2312 - cp936 (gbk) converting only, so I suggest to remove this line from runtime/lang/menu_zh_cn.gb2312.vim: scriptencoding gb2312 Because gbk is a super set of gb2312, so we don't need to do any converting when parsing gb2312-encoded script under gbk environment, and then everything will be OK. I'll report this problem to the maintainer of libiconv as soon as I find out the problem. By the way, thinelephant told me that he sent you a patch of this translation file some weeks ago. Could you please include his change in this patch? We can have these three things to be done in this patch: 1. Add gbk and gb18030 as aliases of cp936; 2. Merge the translation patch of thinelephat. 3. Delete the scriptencoding line in the translation file. Best regards, Edward L. Fox
Re: Temporary solution (was: Malformed character ...)
On 8/15/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Edward - As the problem is caused by iconv and we won't be able to fix the problem soon, and this problem influences gb2312 - cp936 (gbk) converting only, so I suggest to remove this line from runtime/lang/menu_zh_cn.gb2312.vim: scriptencoding gb2312 Because gbk is a super set of gb2312, so we don't need to do any converting when parsing gb2312-encoded script under gbk environment, and then everything will be OK. I'll report this problem to the maintainer of libiconv as soon as I find out the problem. OK, I'll disable this line. By the way, thinelephant told me that he sent you a patch of this translation file some weeks ago. Could you please include his change in this patch? We can have these three things to be done in this patch: 1. Add gbk and gb18030 as aliases of cp936; 2. Merge the translation patch of thinelephat. 3. Delete the scriptencoding line in the translation file. I think I have done all this now. I'll make a patch for the aliases later. Thanks very much~ - Bram -- hundred-and-one symptoms of being an internet addict: 139. You down your lunch in five minutes, at your desk, so you can spend the rest of the hour surfing the Net. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
[OT] Who forwarded my message to eBay?
Hi Vimmers, Somebody in this mailing list had forwarded one of my post to eBay customer support center. I think this mail puzzled eBay so much, although they still promised that they will still try their best to help me with my problem. Here is the response from eBay customer support: 8 Dear eBay Member, Thank you for writing to eBay. I am sorry to inform you that after reading your email, I am unclear as to the exact problem you are experiencing. I am ready to help you with this issue, but for me to help, I need you to send in more information. This will help me answer your question correctly. Please send back a detailed explanation of your problem and I will reply to you very quickly. I appreciate your patience and understanding regarding this matter and I am sorry for any inconvenience caused to you. Sincerely, Shania K. eBay Customer Support _ Original Message Follows: - Hi Bram, On 8/12/06, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] You may have uncovered a bug that went unnoticed so far. Please try to discover what causes this problem. I can't guess why the last character is messed up, looks strange.
Re: failure notice
On 8/13/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: [...] Edward had it on Windows. From :help encoding-values I gather that Chinese and prc are alias to cp936 / euc-cn. Maybe gbk and gb18030 can be added to the family? I'm using Debian Etch. But I had a look at the Windoze system and found that cp936 is supported well in both Linux and Windoze, however, GBK is not supported by any of them. euc-cn is an alias of GB2312, which is only a subset of GBK. So we should not put them together. GB18030 is not exactly the same with GBK but 99% of them is the same, the remaining different part is cared by nobody in the world, and is very very complicated and very very difficult to support. Moreover, very few X servers support this encoding. So I suggest to alias GB18030 to cp936, too, simply and wrongly. :-) After having discussed about the charset, I think it's right time to do some work on the malformed characters in the toolbar tooltips. I made a patch and solved the problem yesterday (or at least it was seemed to be solved). Can anybody review my changes and give some suggestions? Thanks. http://groups.yahoo.com/group/vim/message/72396 Best regards, Tony.
Re: failure notice
On 8/13/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
[removed the Vim maillist, this is development only]
Edward L. Fox wrote:
On 8/12/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
[...]
You may have uncovered a bug that went unnoticed so far. Please try to
discover what causes this problem. I can't guess why the last character
is messed up, looks strange.
I think I solved the problem! That was caused by iconv.
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
The parameter inbytesleft and outbytesleft should all include the
trailing '\0' byte. In the previous version of gvim, we passed the
parameter as the length of the string, excluding the trailing '\0'. So
it is 1 byte less than the correct value.
This is not quite so. iconv() does not require the terminating NUL (it
can also be used to convert part of a string). If it does require the
NUL then iconv() is broken. That's unlikely though.
I wrote a short piece of testing code to test iconv with Chinese
characters. The fact is, if the last character is a Chinese character,
it is always malformed after converting. So I think it should be
necessary to pass the length including the trailing '\0' to iconv.
8
#include iconv.h
int main(void)
{
char inbuffer[256];
char outbuffer[256];
int fd;
fd = iconv_open(cp936, euc-cn);
for (;;)
{
int inlength, outlength;
char *inptr, *outptr;
gets(inbuffer);
inlength = strlen(inbuffer);
outlength = 256;
if (inlength == 0)
break;
inptr = inbuffer;
outptr = outbuffer;
iconv(fd, inptr, inlength, outptr, outlength);
printf(%s\n, outbuffer);
}
iconv_close(fd);
return 0;
}
8
Your change suggests that the length that is passed should be one more.
Thus only one byte of the last double-byte character is currently
converted. I can't quickly figure out where the wrong length is
computed or passed. You probably already know the call stack, please
have a look at where the length comes from. It's probably an off-by-one
error somewhere.
I traced the code again and again but nothing special happened. You
called string_convert and pass 0 as the length of the string, so in
string_convert_ext you calculates the length of the string with
STRLEN, then call iconv_string, last iconv. There is nothing wrong
with the length anywhere. So... Maybe it is still iconv's fault.
[...]
Regards,
Edward L. Fox
Re: failure notice
[...] I traced the code again and again but nothing special happened. You called string_convert and pass 0 as the length of the string, so in string_convert_ext you calculates the length of the string with STRLEN, then call iconv_string, last iconv. There is nothing wrong with the length anywhere. So... Maybe it is still iconv's fault. Sorry all. I did more tests and searched more documents and found that it was a bug of libiconv, not gvim. The problem occurs only when converting gb2312 to gbk. I'm trying to debug libiconv... [...] Ashamed Edward L. Fox
Re: failure notice
On 8/12/06, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] But gvim doesn't support an encoding named 'gbk'. If the system encoding is 'gbk', the menu and toolbar get malformed. What do you mean by system encoding? How does Vim see this? I meant the $LANG variable. GBK is right an alias of cp936, so it is proper to add this alias entry into mbyte.c. But the situation with GB18030 was much more complicated and the current version of gvim is not able to handle it correctly. About GB18030 there is another long and not-so-funny but ridiculous story. If you like, I can tell you the detailed GOSSIP later... Because over 99% part of GB18030 and GBK is the same, and the remaining part is too difficult to handle, I want to set GB18030 as another alias of cp936. Do you think it is OK? [...] You may have uncovered a bug that went unnoticed so far. Please try to discover what causes this problem. I can't guess why the last character is messed up, looks strange. In fact this bug was noticed years before. But most of the Chinese people decided to tolerate this situation. Anyway, I'm going to work on~ [...] Regards, Edward L. Fox
Re: failure notice
Hi Bram,
On 8/12/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
[...]
You may have uncovered a bug that went unnoticed so far. Please try to
discover what causes this problem. I can't guess why the last character
is messed up, looks strange.
I think I solved the problem! That was caused by iconv.
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
The parameter inbytesleft and outbytesleft should all include the
trailing '\0' byte. In the previous version of gvim, we passed the
parameter as the length of the string, excluding the trailing '\0'. So
it is 1 byte less than the correct value.
As we know, every Chinese character is presented with 2 bytes in GBK encoding:
AABBCCDD
\--/
4 characters
Because we passed the parameter as the length of the string (8 in this
example), so iconv treated the input string as 1 byte less (7 in this
example), then the 2nd but last letter was not able to be converted
because it is only half of a character, so gvim changed it to a
question mark:
AABBCC?D
After that, gvim tried to convert the remaining 1 byte to the target
encoding but also failed. Then vim changed it to a question mark, too.
AABBCC??
That is why every last character of the tooltip became 2 question
marks. Menu doesn't get malformed because most of the menu items are
not ended with a Chinese character. In fact, some menu item ends with
Chinese character also get malformed.
[...]
It's quite simple after finding out the problem. Here is the patch, in
which I also alias GBK and GB18030 to cp936. That solved the previous
problem I requested:
*** src/mbyte.c2006-05-14 20:32:49.0 +0800
--- ../vim7.build/vim7/src/mbyte.c 2006-08-12 19:22:06.0 +0800
***
*** 372,377
--- 372,379
{5601, IDX_EUC_KR},/* Sun: KS C 5601 */
{euccn, IDX_EUC_CN},
{gb2312,IDX_EUC_CN},
+ {gbk, IDX_CP936},
+ {gb18030, IDX_CP936},
{euctw, IDX_EUC_TW},
#if defined(WIN3264) || defined(WIN32UNIX) || defined(MACOS)
{japan, IDX_CP932},
***
*** 3250,3256
}
to = (char *)result + done;
! tolen = len - done - 2;
/* Avoid a warning for systems with a wrong iconv() prototype by
* casting the second argument to void *. */
if (iconv(vcp-vc_fd, (void *)from, fromlen, to, tolen)
--- 3252,3259
}
to = (char *)result + done;
! tolen = len - done - 1;
! ++fromlen;
/* Avoid a warning for systems with a wrong iconv() prototype by
* casting the second argument to void *. */
if (iconv(vcp-vc_fd, (void *)from, fromlen, to, tolen)
Best Regards,
Edward L. Fox
Re: failure notice
Hi Bram,
On 8/12/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
[...]
You may have uncovered a bug that went unnoticed so far. Please try to
discover what causes this problem. I can't guess why the last character
is messed up, looks strange.
I think I solved the problem! That was caused by iconv.
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
The parameter inbytesleft and outbytesleft should all include the
trailing '\0' byte. In the previous version of gvim, we passed the
parameter as the length of the string, excluding the trailing '\0'. So
it is 1 byte less than the correct value.
As we know, every Chinese character is presented with 2 bytes in GBK encoding:
AABBCCDD
\--/
4 characters
Because we passed the parameter as the length of the string (8 in this
example), so iconv treated the input string as 1 byte less (7 in this
example), then the 2nd but last letter was not able to be converted
because it is only half of a character, so gvim changed it to a
question mark:
AABBCC?D
After that, gvim tried to convert the remaining 1 byte to the target
encoding but also failed. Then vim changed it to a question mark, too.
AABBCC??
That is why every last character of the tooltip became 2 question
marks. Menu doesn't get malformed because most of the menu items are
not ended with a Chinese character. In fact, some menu item ends with
Chinese character also get malformed.
[...]
It's quite simple after finding out the problem. Here is the patch, in
which I also alias GBK and GB18030 to cp936. That solved the previous
problem I requested:
*** src/mbyte.c2006-05-14 20:32:49.0 +0800
--- ../vim7.build/vim7/src/mbyte.c 2006-08-12 19:22:06.0 +0800
***
*** 372,377
--- 372,379
{5601, IDX_EUC_KR},/* Sun: KS C 5601 */
{euccn, IDX_EUC_CN},
{gb2312,IDX_EUC_CN},
+ {gbk, IDX_CP936},
+ {gb18030, IDX_CP936},
{euctw, IDX_EUC_TW},
#if defined(WIN3264) || defined(WIN32UNIX) || defined(MACOS)
{japan, IDX_CP932},
***
*** 3250,3256
}
to = (char *)result + done;
! tolen = len - done - 2;
/* Avoid a warning for systems with a wrong iconv() prototype by
* casting the second argument to void *. */
if (iconv(vcp-vc_fd, (void *)from, fromlen, to, tolen)
--- 3252,3259
}
to = (char *)result + done;
! tolen = len - done - 1;
! ++fromlen;
/* Avoid a warning for systems with a wrong iconv() prototype by
* casting the second argument to void *. */
if (iconv(vcp-vc_fd, (void *)from, fromlen, to, tolen)
Best Regards,
Edward L. Fox
Re: failure notice
Hi vimmers, Sorry for sending this mail for the second time because my previous mail with attachment was rejected by the mail daemon. :-( On 8/11/06, Bram Moolenaar [EMAIL PROTECTED] wrote: [...] The menu.vim file should never change 'encoding'. It should load menus that are appropriate for the current 'encoding' and language. But gvim doesn't support an encoding named 'gbk'. If the system encoding is 'gbk', the menu and toolbar get malformed. In the past two years (or more), all gvim users in mainland China should add the following two lines in their .vimrc if they are using Linux with GBK encoding: set enc=cp936 so $VIMRUNTIME/delmenu.vim so $VIMRUNTIME/menu.vim That's why I had wanted to change the encoding value in menu.vim. :-) If the intention is to have the default for 'encoding' use something specific in $LANG then this must be done in enc_locale() in src/mbyte.c I modified mbyte.c, added gbk as an alias of cp936, then the menubar was displayed properly with the unmodified menu.vim. But there is still some problem with the toolbar - every last character of the tooltip becomes two question marks. I'm trying to debug the code and will send you another patch as soon as I solve the problem. Hope you can offer me some hints, too. :-) [...] Regards, Edward L. Fox
Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
Patch Unofficial Problem:Menu and toolbar: Doesn't display properly when using zh_CN.GBK encoding under Linux. Solution: Use gb2312 to generate the menu and toolbar to get proper display, then use cp936 instead of GBK which is a correct alias under Linux. Files: runtime/menu.vim *** runtime/menu.vim 2006-04-18 06:06:31.0 +0800 --- ../vim7.my/runtime/menu.vim2006-08-09 16:21:03.0 +0800 *** *** 48,53 --- 48,56 same menu file for them. let s:lang = substitute(s:lang, 'iso_8859-15\=$', latin1, ) menutrans clear + if s:lang == zh_cn.gbk || s:lang == zh_cn.gb18030 + set enc=gb2312 + endif exe runtime! lang/menu_ . s:lang . .vim if !exists(did_menu_trans) *** *** 1094,1097 --- 1097,1104 let cpo = s:cpo_save unlet s:cpo_save + if s:lang == zh_cn.gbk || s:lang == zh_cn.gb18030 + set enc=cp936 + endif + vim: set sw=2 :
Re: sh indent script
On 7/20/06, Edward L. Fox [EMAIL PROTECTED] wrote:
Hi VIMmers,
The default sh indent script in VIM7 indent the following sample file this way:
8
#!/bin/sh
SYSTEM=`uname -s`
case $SYSTEM in
Linux)
echo My system is Linux
echo Do Linux stuff here...
;;
FreeBSD)
echo My system is FreeBSD
echo Do FreeBSD stuff here...
;;
*)
echo Unknown system : $SYSTEM
echo I don't what to do...
;;
esac
8
But I preferred the indent of each case label be decreased to the same
level of the case statement, like this:
8
#!/bin/sh
SYSTEM=`uname -s`
case $SYSTEM in
Linux)
echo My system is Linux
echo Do Linux stuff here...
;;
FreeBSD)
echo My system is FreeBSD
echo Do FreeBSD stuff here...
;;
*)
echo Unknown system : $SYSTEM
echo I don't what to do...
;;
esac
8
So I hacked the indent script. Any suggestion and feedback are welcome. :-)
Can anyone hack the script and support this indent flavor, too?
8
#!/bin/sh
SYSTEM=`uname -s`
case $SYSTEM in
Linux)
echo My system is Linux
echo Do Linux stuff here...
;;
FreeBSD)
echo My system is FreeBSD
echo Do FreeBSD stuff here...
;;
*)
echo Unknown system : $SYSTEM
echo I don't what to do...
;;
esac
8
Regards,
Edward L. Fox
I supported the both formats now.
:let g:sh_indent_case_labels = 0 for the first indent style.
case ...
a)
commands
;;
b)
commands
;;
c)
commands
;;
esac
:let g:sh_indent_case_labels = 1 for the second indent style.
case ...
a)
commands
;;
b)
commands
;;
c)
commands
;;
esac
Here is the patch:
Patch unofficial
*** /usr/local/share/vim/vim70/indent/sh.vim2006-07-24
11:12:22.0 +0800
--- runtime/indent/sh.vim 2006-07-30 14:20:45.0 +0800
***
*** 1,7
Vim indent file
! Language: Shell Script
! Maintainer: Nikolai Weibull [EMAIL PROTECTED]
! Latest Revision: 2006-04-19
if exists(b:did_indent)
finish
--- 1,8
Vim indent file
! Language:Shell Script
! Maintainer:Nikolai Weibull [EMAIL PROTECTED]
! Modified: Edward L. Fox [EMAIL PROTECTED]
! Last Modified: 2006-07-30 14:20:45
if exists(b:did_indent)
finish
***
*** 9,15
let b:did_indent = 1
setlocal indentexpr=GetShIndent()
! setlocal indentkeys+==then,=do,=else,=elif,=esac,=fi,=fin,=fil,=done
setlocal indentkeys-=:,0#
if exists(*GetShIndent)
--- 10,16
let b:did_indent = 1
setlocal indentexpr=GetShIndent()
! setlocal indentkeys+==then,=do,=else,=elif,=esac,=fi,=fin,=fil,=done,)
setlocal indentkeys-=:,0#
if exists(*GetShIndent)
***
*** 27,50
Add a 'shiftwidth' after if, while, else, case, until, for, function()
Skip if the line also contains the closure for the above
let ind = indent(lnum)
let line = getline(lnum)
if line =~ '^\s*\(if\|then\|do\|else\|elif\|case\|while\|until\|for\)\'
\ || line =~ '^\s*\\k\+\\s*()\s*{'
\ || line =~ '^\s*{'
if line !~ '\(esac\|fi\|done\)\\s*$' line !~ '}\s*$'
let ind = ind + sw
endif
endif
Subtract a 'shiftwidth' on a then, do, else, esac, fi, done
Retain the indentation level if line matches fin (for find)
let line = getline(v:lnum)
! if (line =~ '^\s*\(then\|do\|else\|elif\|esac\|fi\|done\)\' ||
line =~ '^\s*}')
\ line !~ '^\s*fi[ln]\'
let ind = ind - sw
endif
return ind
endfunction
--- 28,64
Add a 'shiftwidth' after if, while, else, case, until, for, function()
Skip if the line also contains the closure for the above
+
let ind = indent(lnum)
let line = getline(lnum)
if line =~ '^\s*\(if\|then\|do\|else\|elif\|case\|while\|until\|for\)\'
\ || line =~ '^\s*\\k\+\\s*()\s*{'
+ \ || line =~ '^\s*[^(]\+\s*)'
\ || line =~ '^\s*{'
if line !~ '\(esac\|fi\|done\)\\s*$' line !~ '}\s*$'
let ind = ind + sw
endif
endif
+ if line =~ '^\s*case\' g:sh_indent_case_labels
+ let ind = ind + sw
+ endif
+
Subtract a 'shiftwidth' on a then, do, else, esac, fi, done
Retain the indentation level if line matches fin (for find)
let line = getline(v:lnum)
! if (line =~ '^\s*\(then\|do\|else\|elif\|esac\|fi\|done\)\'
! \ || line =~ '^\s*[^(]\+\s*)'
! \ || line =~ '^\s*}'
! \ )
\ line !~ '^\s*fi[ln]\'
let ind = ind - sw
endif
+ if line =~ '^\s*esac\' g:sh_indent_case_labels
+ let ind = ind - sw
+ endif
+
return ind
endfunction
svn, cvs
On 6/18/06, Suresh Govindachar [EMAIL PROTECTED] wrote: Hello, Since svn sources haven't been updated, The content in subversion repository is the same with the CVS repository, at most 1 day later. It doesn't update only because Bram had been out for holiday since last month. and since they differs from the cvs sources by CR/LF in some files Give me the list and I'll fix. [...]
Re: SVN and svn:eol-style
On 5/13/06, Brandt, Servatius [EMAIL PROTECTED] wrote: [...] So I suggest to use a svn:eol-style setting of LF instead of native. Previously when I didn't set the svn:eol-style property, all text files were using LF as end-of-line character. Bill complained so I change the end-of-line character to native, in order to please everyone. But now, here is another opinion. As you see, changing the svn:eol-style will cause everyone downloading all modified files again, it will cost about one hour. So I think I should not make any furthur change before the final decision is made. [...] Any opinions to this? - Servatius Servatius Brandt Phone: +49 89 636-41504 Fujitsu Siemens ComputersFax: +49 89 636-48716 EP SW AD C++ Email: [EMAIL PROTECTED]
Re: SVN and svn:eol-style
On 5/11/06, Bill McCarthy [EMAIL PROTECTED] wrote: On Wed 10-May-06 9:43pm -0600, Anduin Withers wrote: Why do you want CR-LF files? A single LF should work just fine. The only place where I know it doesn't work is when you read Make_ivc.mak into Visual Studio. Automatic LF to CR-LF translation always causes trouble somewhere. CVS did it automatically, as long as binaries are properly tagged there shouldn't be (and wasn't, at least for me) a problem. One reason is consistency: This is the behavior CVS had, it is the format the releases are in on the ftp site, it also makes things look better when I edit my .vim files with notepad. Just another request for native line endings. Some days it is better for me to read my mail from newest to oldest - or at least read through everything before replying. Well stated. I now wish I used a different example that notepad - although that is indeed a good one, since every Windows user has it and it is frequently a default in Explorer. Hopefully, the gentleman maintaining the svn repository (Edward L Fox) will talk to the gentleman who properly marked the files in CVS. Well, well, well... I prop-setted most of the file that I recognized. If you find anything wrong or prop missing, plz contact me. The bad news for everyone is, after prop-setting the files, everyone has to download the prop-setted files again. That will cost quite a long time. I have also had no problems with the CVS distribution That's because CVS doens't support that features at all and every text file is forced to use native linebreaks. -- Best regards, Bill
Re: Patch 7.0.001
Hi all, On 5/10/06, Gautam Iyer [EMAIL PROTECTED] wrote: On Tue, May 09, 2006 at 02:37:08PM +0200, Bram Moolenaar wrote: Patch 7.0.001 Problem::set spellsuggest+=10 does not work. (Suresh Govindachar) Solution: Add P_COMMA to the 'spellsuggest' flags. Files: src/option.c Hi Bram, Will your patches be in the subversion source tree? I recently ran svn update, and found no changes from vim7... Unfortunately sourceforge had encountered some unknown errors and I'm not able to log in to the CVS repository these two days. I'm trying to contact the administrators of sourceforge. But if this problem could not be resolved, I'll try to sync the code with the patches manually. Thanks, Gautam -- 'Common' Proof Techniques: 12. Proof by obfuscation -- A long plotless sequence of true and/or meaningless syntactically related statements. Regards, Edward L. Fox
Re: Patch 7.0.001
On 5/10/06, Hisashi T Fujinaka [EMAIL PROTECTED] wrote: version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on chris.i8u.org Disk died and they're hot swapping it. However, hot swapping for those guys is taking overnight. Well, so I'm patching the code with Bram's patch and uploading them to subversion now. On Wed, 10 May 2006, Edward L. Fox wrote: Hi all, On 5/10/06, Gautam Iyer [EMAIL PROTECTED] wrote: On Tue, May 09, 2006 at 02:37:08PM +0200, Bram Moolenaar wrote: Patch 7.0.001 Problem::set spellsuggest+=10 does not work. (Suresh Govindachar) Solution: Add P_COMMA to the 'spellsuggest' flags. Files: src/option.c Hi Bram, Will your patches be in the subversion source tree? I recently ran svn update, and found no changes from vim7... Unfortunately sourceforge had encountered some unknown errors and I'm not able to log in to the CVS repository these two days. I'm trying to contact the administrators of sourceforge. But if this problem could not be resolved, I'll try to sync the code with the patches manually. Thanks, Gautam -- 'Common' Proof Techniques: 12. Proof by obfuscation -- A long plotless sequence of true and/or meaningless syntactically related statements. Regards, Edward L. Fox -- Hisashi T Fujinaka - [EMAIL PROTECTED] BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte
Re: Network problem
On 5/5/06, Edward L. Fox [EMAIL PROTECTED] wrote: Hi VIMmers, I'm sorry that I'm not able to sync the SVN repository with the CVS repository on time today, because the network is suffering some problems. I had tried different routes but all failed. Maybe there is something wrong with the main gateways of the whole country. :-( I'll sync the code as soon as the network recovers. Please wait for my notice. Best wishes~ OK now! The newest snapshot was uploaded to subversion repository. Bless~ Regards, Edward Leap Fox
Network problem
Hi VIMmers, I'm sorry that I'm not able to sync the SVN repository with the CVS repository on time today, because the network is suffering some problems. I had tried different routes but all failed. Maybe there is something wrong with the main gateways of the whole country. :-( I'll sync the code as soon as the network recovers. Please wait for my notice. Best wishes~ Regards, Edward Leap Fox
Network problem
Hi VIMmers, I'm sorry that I'm not able to sync the SVN repository with the CVS repository on time today, because the network is suffering some problems. I had tried different routes but all failed. Maybe there is something wrong with the main gateways of the whole country. :-( I'll sync the code as soon as the network recovers. Please wait for my notice. Best wishes~ Regards, Edward Leap Fox
Re: Svn and patches
On 4/28/06, Bram Moolenaar [EMAIL PROTECTED] wrote: Suresh Govindachar wrote: Does the stuff downloaded from svn include all the latest patches? I suspect it does since the version from yesterday's download says 7.0f02. If so, how latest? Meaning, I suppose Bram commits before sending notice of the patch to the mailing list -- how much after that will it appear on a svn checkout? Hi, I'm the subversion repository maintainer. I sync the subversion repository with the CVS repository everyday at about 9:00 (+0800), or 1:00 (GMT). So if you checkout the code at about 2:00 (GMT), you can get the latest version. :-) I recommend getting sources via svn -- it was really very trivial -- much simpler than getting and starting with tar.bz2 and extra.tar.gz. I mostly make a new snapshot every night. They should be in SVN within some hours. I don't know exactly how often Edward updates it, but you can assume there is a fresh Vim every morning. The zip archive is available earlier. -- An indication you must be a manager: You give constructive feedback to your dog. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
CVS updated?
Is the idea that this is a complete switch to SVN, or will the CVS tree still be updated once it's back online? I'm not sure at this moment. Bram and other VIM developers uses not only CVS it self, but also a lot of other scripts which relies strongly on the output information of cvs. So switching to svn will cost more effect. Any way, I'll try my best to switch the whole project to svn, without disturbing the other developers too much. -Original Message- From: Edward L. Fox [mailto:[EMAIL PROTECTED] Maybe we should go to Subversion at SourceForge after all, since their SVN servers are not experiencing hardware problems. Well, is there someone who can transfer the CVS stuff into Subversion? And repeat that for every snapshot? I can do that. My only question is, should I use the subversion service supplied by sourceforge, or use some other host? If use the sourceforge svn service, please grant me the corresponding privilege, my sf ID is edyfox. If you decide to use other host, I'll make a site available in two or three days. We can do this on SourceForge, I suppose. I have added you to the Vim group. Use it responsibly! I'm doing the work now but unfortunately I find that I don't have enough privilege to enable the subversion service nor access the svn repository. Could you grant me the privilege, too?
