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: 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: 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
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: [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~
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
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: 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
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///
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
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: 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
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
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: 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
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?
