Re: Vim version 7.1a BETA has been released

[Gary Johnson]

On 2007-05-06, Bram Moolenaar [EMAIL PROTECTED] wrote:
 Gary Johnson wrote:
 
  I noticed that filetype.vim does not include the patch that I 
  submitted to this list 2006-07-25 to fix the recognition of mutt 
  temporary files on SunOS.  Is there something else I can do to have 
  this patch accepted?
 
 It was still in the todo list.  There are many items I still didn't have
 time for, unfortunately.  I assume you have properly tested this change.
 I'll include this one now.

Thank you.  I was concerned that it hadn't made it onto the list.  I 
didn't realize you had such a backlog of changes.

I've been using it in my $VIMRUNTIME/filetype.vim since July without 
any problems or errors that I know of.

Best regards,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA

Re: problem with win32 vim 7.1a.001

[A.J.Mechelynck]

Michael Wookey 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?




Make sure that VIMRUNTIME is _not_ defined in your environment (in XP or 
later: Control Panel = System = Adevanced = Environment variables; there 
are two sets, one for all users and one specific to your login name). VIM 
may be either undefined or set at C:\Vim; NOT at C:\Vim\Vim70 unless your 
distribution is in C:\Vim\Vim70\Vim70 (7.0) and/or C:\Vim\vim70\Vim71a (7.1), 
both of which are quite atypical to say the least.


Your (user) _vimrc can be either in $HOME (wherever Vim sets it) or, on a 
single-user system only, in $VIM. The problem with the latter is that it's the 
same for all users (all login names).


At Vim startup, if VIM and VIMRUNTIME are both undefined, and (g)vim was 
loaded from C:\Vim\vim71a\, that directory will become $VIMRUNTIME and its 
parent will become $VIM. Vim will then look for runtime files there and in its 
subfolders.


Warnings:
1. I don't think you can use the same server to rsync your 7.1 runtimes as 
your 7.0: it would pick the 7.0 files, including help files with 'For Vim 7.0 
in their first line. AFAICT, the 7.1 runtimes consist of those distributed for 
7.1a.000 plus one modification in the latest patch. Couldn't find anything 
else at ftp.vim.org.
2. The parent of the src/ and runtime/ (and a few other) directories from 
yource source 7.1 distro should be named vim71a (which is where the archives 
unpack to) to avoid conflict with the 7.0 source. The first 7.0 compile MUST 
be from scratch, then you may compile only the changes but only if your 
featureset stays the same (e.g. big, +gui +ole +perl/dyn +python/dyn -ruby 
-tcl -mzscheme +multibyte_ime/dyn etc...). To force a full rebuild, use make 
-f makefile name clean or make -f makefilename distclean prior to 
rebuilding.
3. For more details, see 
http://users.skynet.be/antoine.mechelynck/vim/compile.htm but replace vim70 
(wherever it appears) by vim71a.



Best regards,
Tony.
--
If you think education is expensive, try ignorance.
-- Derek Bok, president of Harvard

Re: Vim version 7.1a BETA has been released

[Gary Johnson]

On 2007-05-06, Gary Johnson [EMAIL PROTECTED] wrote:
 On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote:

   Compiles as a breeze :-).
 
 Yes indeed.  I've compiled it so far on SunOS 5.8 and HP-UX 10.20.  
 I may try Cygwin if I'm feeling adventurous enough.  I've never done 
 that except from Cygwin sources.

Well, that was really easy.  I built just the console version for 
Cygwin and it seems to work fine in PuTTY over an ssh connection.

Regards,
Gary

-- 
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
 | Spokane, Washington, USA

RE: problem with win32 vim 7.1a.001

[Michael Wookey]

  Any ideas?
 
 Maybe you can rename all your directories named Vim70 to Vim71a.

Yep - that was it.  

C:\Vim\vim70 was renamed to C:\Vim\vim71a and all is well.

Thanks!  (and also thanks to Tony for the troubleshooting hints)

Odp: problem with win32 vim 7.1a.001

[Mikołaj Machowski]

I've had similar problem with 7.1a BETA (from CVS) on Mandriva 2006.

Solved by removing old directory and fresh checkout.

m.


Zobacz, jaką walkę stoczy superbohater, by ocalić siebie
i swych bliskich. A największa bitwa rozegra się w jego duszy.
SPIDER-MAN 3 w kinach od 4 maja.
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fspiderman3.htmlsid=1122

Re: Vim version 7.1a BETA has been released

[Matthew Winn]

On Sun, 06 May 2007 14:46:22 +0200, A.J.Mechelynck
[EMAIL PROTECTED] wrote:

 Michael Henry wrote:
  Gary Johnson wrote:
  On 2007-05-05, A.J.Mechelynck [EMAIL PROTECTED] wrote:
   (Warning: In the ln command as used here, the target name comes 
  before the  link name. I find this counter-intuitive.)
 
  It's not just me then.  I have to think carefully about that every 
  time I use ln.
  
  I used to find this hard to remember until I realized that 'ln' and 'cp' 
  are very similar.  The 'cp' command copies one or more sources to a 
  destination; the 'ln' command links one or more sources to a destination 
  as well.  I tend to think of 'ln -s' as copy using symlinks.  The 
  order and meaning of the arguments is the same between the commands, 
  which I now find consistent and intuitive.
 
 The problem is, cp -v file1 file2 outputs
 
   `file1' - `file2'
 
 (the data has been copied from file1 to file2) but ln -sv file1 file2 
 outputs
 
   file2 - file1
 
 (file2 is now a link pointing to file1). I still have to call up the help 
 or 
 the manual every time I invoke it.

Just remember that for all of cp, ln and mv, the existing file comes
first.

I think the confusion arises because people think of ln as create a
link, so they see ln x y as create a link x..., which it isn't.
It makes more sense if you think of it this way:

mv x ymove file x to file y
cp x ycopy file x to file y
ln x ylink file x to file y

-- 
Matthew Winn

Compiling vim in mingw.

[Markus Trenkwalder]

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

Re: Vim version 7.1a BETA has been released

[Michael Henry]

Matthew Winn wrote:

On Sun, 06 May 2007 14:46:22 +0200, A.J.Mechelynck
[EMAIL PROTECTED] wrote:


Michael Henry wrote:
I used to find this hard to remember until I realized that 'ln' and 'cp' 
are very similar.  



The problem is, cp -v file1 file2 outputs

`file1' - `file2'

(the data has been copied from file1 to file2) but ln -sv file1 file2 
outputs

file2 - file1



It makes more sense if you think of it this way:

mv x ymove file x to file y
cp x ycopy file x to file y
ln x ylink file x to file y


Agreed, this is what makes the parameter order intuitive and consistent 
to me.  But I can see confusion creeping in when the '-v' flag of the 
'ln' command reverses the order of the filenames, as shown in Tony's 
example above.  Fortunately, I almost never use '-v' so it can't confuse 
me :-)


Michael Henry

Re: Compiling vim in mingw.

[A.J.Mechelynck]

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

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: syntax highlighting addition

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I know this is sortof late notice, but it would be great if this could go in 7.1
final :)

 The empty comment is still there.  Just leave that line blank.  No
 biggie, of course, just aesthetics.

i could have sworn i fixed it. this time, though, it really is fixed. :)

 runtime! syntax/python.vim

 Just to make sure: Python is allowed anywhere in a conary recipe?

correct. a recipe is a special type of python file

 syn match   conaryMacro %(\w*)[sd] contained
 syn match   conaryBadMacro  %(\w*)[^sd] contained  no final marker

 OK, so you can have the following:

 %()s

 or should it be %(\w\+)[sd]

you're right. fixed

   HiLink conaryUseFlag  Typedef

 Substitute that with
 hi def link conaryrecipeMacro Macro
 :
 :

fixed

 (If conary recipe macros aren't much like macros in C, then perhaps
 Special is better.  Also note the linking of a generic group to
 function and then other groups linking to them so that a user can
 change them all en masse, to something they like.)

fixed

 That HiLink cruft is also Vim5 compatibility stuff.  And remove the if
 statement.

fixed

 let b:current_syntax = recipe

 This should be

 let b:current_syntax = conaryrecipe

fixed

smithj

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)

iD8DBQFGP13N0e1Yawpq2XMRAk7+AKCZoBtDszC/FZpK6m9bZFPMKXHnoQCgjVGu
gstfvNHYnhUHmyzQ8sMxAvI=
=Y9Ve
-END PGP SIGNATURE-
 Vim syntax file
 Language: Conary Recipe
 Maintainer:   rPath Inc http://www.rpath.com
 Updated:  2007-05-07

if exists(b:current_syntax)
  finish
endif

runtime! syntax/python.vim
syn keyword conarySFunction mainDir addAction addSource addArchive addPatch
syn keyword conarySFunction addRedirect addSvnSnapshot addMercurialSnapshot
syn keyword conarySFunction addCvsSnapshot

syn keyword conaryGFunction add addAll addNewGroup addReference createGroup
syn keyword conaryGFunction addNewGroup startGroup remove removeComponents
syn keyword conaryGFunction replace setByDefault setDefaultGroup 
syn keyword conaryGFunction setLabelPath addCopy setSearchPath

syn keyword conaryBFunction Run Automake Configure ManualConfigure 
syn keyword conaryBFunction Make MakeParallelSubdir MakeInstall
syn keyword conaryBFunction MakePathsInstall CompilePython
syn keyword conaryBFunction Ldconfig Desktopfile Environment SetModes
syn keyword conaryBFunction Install Copy Move Symlink Link Remove Doc
syn keyword conaryBFunction Create MakeDirs disableParallelMake
syn keyword conaryBFunction ConsoleHelper Replace SGMLCatalogEntry
syn keyword conaryBFunction XInetdService XMLCatalogEntry TestSuite
syn keyword conaryBFunction PythonSetup

syn keyword conaryPFunction NonBinariesInBindirs FilesInMandir 
syn keyword conaryPFunction ImproperlyShared CheckSonames CheckDestDir
syn keyword conaryPFunction ComponentSpec PackageSpec 
syn keyword conaryPFunction Config InitScript GconfSchema SharedLibrary
syn keyword conaryPFunction ParseManifest MakeDevices DanglingSymlinks
syn keyword conaryPFunction AddModes WarnWriteable IgnoredSetuid
syn keyword conaryPFunction Ownership ExcludeDirectories
syn keyword conaryPFunction BadFilenames BadInterpreterPaths ByDefault
syn keyword conaryPFunction ComponentProvides ComponentRequires Flavor
syn keyword conaryPFunction EnforceConfigLogBuildRequirements Group
syn keyword conaryPFunction EnforceSonameBuildRequirements InitialContents
syn keyword conaryPFunction FilesForDirectories LinkCount
syn keyword conaryPFunction MakdeDevices NonMultilibComponent ObsoletePaths
syn keyword conaryPFunction NonMultilibDirectories NonUTF8Filenames TagSpec
syn keyword conaryPFunction Provides RequireChkconfig Requires TagHandler
syn keyword conaryPFunction TagDescription Transient User UtilizeGroup
syn keyword conaryPFunction WorldWritableExecutables UtilizeUser
syn keyword conaryPFunction WarnWritable Strip CheckDesktopFiles

 Most destdirPolicy aren't called from recipes, except for these
syn keyword conaryPFunction AutoDoc RemoveNonPackageFiles TestSuiteFiles
syn keyword conaryPFunction TestSuiteLinks

syn match   conaryMacro %(\w\+)[sd] contained
syn match   conaryBadMacro  %(\w*)[^sd] contained  no final marker
syn keyword conaryArchescontained x86 x86_64 alpha ia64 ppc ppc64 s390
syn keyword conaryArchescontained sparc sparc64
syn keyword conarySubArches contained sse2 3dnow 3dnowext cmov i486 i586
syn keyword conarySubArches contained i686 mmx mmxext nx sse sse2
syn keyword conaryBad   RPM_BUILD_ROOT EtcConfig InstallBucket subDir 
subdir 
syn keyword conaryBad   RPM_OPT_FLAGS 
syn cluster conaryArchFlags contains=conaryArches,conarySubArches
syn match   conaryArch  Arch\.[a-z0-9A-Z]\+ 
contains=conaryArches,conarySubArches
syn match   conaryArch  Arch\.[a-z0-9A-Z]\+ 

Vim version 7.1a BETA -- runtime files ?

[Yakov Lerner]

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

ctrl-c oddity with visual block insert

[James Vega]

Since C-c is supposed to act like Esc in most circumstances, one
would expect that pressing C-c to end Insert mode during a visual
block insert would prepend the text to all selected lines.  In fact,
This was the behavior in versions of Vim prior to vim7.  As it currently
stands, pressing C-c will only insert the text on the first line of
the visually selected block unless the user has at some point setup a
C-c vmap.  Example:

vim -u NONE -N
:insert
foo
bar
baz
.
ggC-vjjIXXC-c

This will only insert XX at the front of the first line.  If we instead
do the following, the XX will be inserted at the front of every line.

vim -u NONE -N
:vmap C-c nop
:insert
foo
bar
baz
.
ggC-vjjIXXC-c

The presence of the C-c vmap isn't important.  You can vunmap it
immediately after.  It's the mere act of defining a C-c vmap that
causes C-c to act as expected.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Compiling vim in mingw.

[Bram Moolenaar]

Markus Trenkwalder wrote:

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

What does TOOLTIPTEXTA have to do with this?  I don't understand why you
try to solve it this way.

Someone else also reported this problem while it worked OK earlier.
Perhaps there is something wrong with the way you obtained the sources?

-- 
Proof techniques #2: Proof by Oddity.
SAMPLE: To prove that horses have an infinite number of legs.
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.

 /// 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: syntax highlighting addition

[Bram Moolenaar]

Jonathan Smith wrote:

 I know this is sortof late notice, but it would be great if this could
 go in 7.1 final :)
 
  The empty comment is still there.  Just leave that line blank.  No
  biggie, of course, just aesthetics.
 
 i could have sworn i fixed it. this time, though, it really is fixed. :)
 
  runtime! syntax/python.vim
 
  Just to make sure: Python is allowed anywhere in a conary recipe?
 
 correct. a recipe is a special type of python file
 
  syn match   conaryMacro %(\w*)[sd] contained
  syn match   conaryBadMacro  %(\w*)[^sd] contained  no final marker
 
  OK, so you can have the following:
 
  %()s
 
  or should it be %(\w\+)[sd]
 
 you're right. fixed
 
HiLink conaryUseFlag  Typedef
 
  Substitute that with
  hi def link conaryrecipeMacro Macro
  :
  :
 
 fixed
 
  (If conary recipe macros aren't much like macros in C, then perhaps
  Special is better.  Also note the linking of a generic group to
  function and then other groups linking to them so that a user can
  change them all en masse, to something they like.)
 
 fixed
 
  That HiLink cruft is also Vim5 compatibility stuff.  And remove the if
  statement.
 
 fixed
 
  let b:current_syntax = recipe
 
  This should be
 
  let b:current_syntax = conaryrecipe
 
 fixed

The only thing that I now spot is that the syntax items start with
conary instead of conaryrecipe.  That's a tiny issue though, since
if there is another conaryXXX syntax you can make sure there are no
conflicts.

I'll include the syntax file now.

-- 
hundred-and-one symptoms of being an internet addict:
80. At parties, you introduce your spouse as your service provider.

 /// 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: Where to find 7.1a patchlevels runtimes? (Was: patch 7.1a.001)

[Bram Moolenaar]

Tony Mechelynck wrote:

 Bram Moolenaar wrote:
  Patch 7.1a.001
  Problem:Crash when downloading a spell file.  (Szabolcs Horvat)
  Solution:   Avoid that did_set_spelllang() is used recursively when a new
  window is opened for the download.
  Also avoid wiping out the wrong buffer.
  Files:  runtime/autoload/spellfile.vim, src/buffer.c, src/ex_cmds.c,
  src/spell.c
 [...]
 
 After a little hunting, I found this patch on the ftp server too (with
 README, MD5 and MD5SUMS):
 
 ftp://ftp.vim.org/pub/vim/unstable/patches/7.1a/

That's right.

 Note: I prefer not to feed the email itself to the patch program, because:
 - my ISP's routers sometimes autoconvert the contents between 8-bit and 
 quoted-printable; and the latter make the patch program choke;
 - if I see several patches published while I was away or asleep, by FTP I can 
 get them all to where patch will find them.
 - the patch directory on FTP includes a table of contents, README
 
 I notice this patch modifies one runtime file. This reminds me that runtime 
 updates are not always reflected in patches. Do the files in 
 ftp://ftp.vim.org/pub/vim/runtime/ (and the equivalent rsync repository, 
 ftp.nluug.nl::Vim/runtime/ ) apply to 7.0 only, or to both 7.0 and 7.1? (The 
 latest changes there are for a large number of spelling dictionaries.)

They are for both.  There are no (recent) source code changes that are
required for the updated runtime files.

 On thinking back, I would suspect they /aren't/ the same, since the
 first line of each helpfile mentions either 7.0 or 7.1a -- so at least
 the contents of the doc/ subfolders are different. So -- will runtime
 upgrades for 7.1 beta be always reflected in patches, or else will
 there be a runtime server -- and where?
 (ftp://pub/vim/unstable/runtime/ contains only one item yet: a
 softlink to the main spell subfolder.)

There were runtime files here during the 7.0 beta testing, but I don't
think they are useful now.

 Hm... I see a snapshot zip,
 http://ftp.vim.org/pub/vim/unstable/snapshot/vim-7.1a.zip ,but it's
 more than 24h older than the patch, while it's only about 2h younger
 than the 7.0.000 tar.gz and tar.bz2 archives so I guess it's 7.1a.000
 in one big economy package...

It's almost the same.  I had trouble getting the CVS server updated, and
this snapshot went together with that update.  I don't think it adds
anything now, it was for when there was no 7.0x release yet.

-- 
hundred-and-one symptoms of being an internet addict:
77. The phone company asks you to test drive their new PBX system

 /// 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.1a.001

[Bram Moolenaar]

Chris Sutcliffe wrote:

 Hey All,

  Patch 7.1a.001

 I managed to compile 7.1a from cvs yesterday.  I went and did a cvs up
 to grab this patch and I am now getting this error:

 gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA'
 gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'
 mingw32-make: *** [gobj/gui_w32.o] Error 1

 I'm guessing it's not a result of this patch, since this patch did not
 affect gui_w32.c.  Perhaps there was something changed in CVS (I
 notice the update grabbed a whole bunch of files)?

I don't know what happened.  When I checkout the files from CVS now I
don't see a problem in gui_w32.c.  Was this a temporary problem?

-- 
hundred-and-one symptoms of being an internet addict:
83. Batteries in the TV remote now last for months.

 /// 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: Vim version 7.1a BETA -- runtime files ?

[Bram Moolenaar]

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?

-- 
hundred-and-one symptoms of being an internet addict:
84. Books in your bookcase bear the names Bongo, WinSock and Inside OLE

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

surprised by beta

[scott]

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

Re: Compiling vim in mingw.

[Suresh Govindachar]

  Bram Moolenaar wrote:
   Markus Trenkwalder wrote:
  
  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

  I get the same error message.  I recursively grepped for
  NMTTDISPINFO and examined the output, but did not find any
  redefinition!  No clue where the compiler is finding the
  redefinitions.

   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
   
   What does TOOLTIPTEXTA have to do with this?  I don't understand
   why you try to solve it this way.
   
   Someone else also reported this problem while it worked OK
   earlier.  Perhaps there is something wrong with the way you
   obtained the sources?

  (Tony reported working around the error message by not using svn.)

  I got the sources from svn the same why I have always been getting
  the sources (the whole process of get sources, build, deploy,
  update runtime is automated in scripts).

  --Suresh

Re: Vim version 7.1a BETA -- runtime files ?

[Yakov Lerner]

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


diffs
Description: Binary data


diff-vim-ftp-svn.sh
Description: Bourne shell script

Re: Vim version 7.1a BETA -- runtime files ?

[Yakov Lerner]

On 5/8/07, Yakov Lerner [EMAIL PROTECTED] wrote:

Full diffs are attached. Diffs are produced by the script diff-vim-ftp-svn.sh,
also attached.


Re-sending attachments which came out zero-length in previous email.

Yakov


diffs
Description: Binary data


diff-vim-ftp-svn.sh
Description: Bourne shell script

Re: VimWiki - again - but with a brand new option

[Ian Tegebo]

On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote:

Hi all

Independent of the implementation used, I suggest to develop good
guidelines. The Wiki should be really valuable and not redundant to
vim-tips or mailing-lists.

I would like to make another implementation independent suggestion; one could
make a VimWiki more valuable by importing the _extremely_ valuable vim
helpfiles into it.

For example, I would love to be able to quickly correct spelling mistakes or
contribute to plugin helpfiles a la a Wiki interface.  I could then imagine
updating my local helpfiles through the Wiki interface via a sync-plugin.

The Wiki would ideally understand how to link to vim-scripts and vim-tips like
vimonline currently does.  As a bonus, mailing-list posts would also linkable
and magical indexing would populate the bottom of each Wiki page with relevant
search results from the list similar to O'Reilly's Safari.

It's fun to dream!  I'm serious about getting the helpfiles imported into the
Wiki though.  I know about the VimDoc project; I think this could be the next
evolution in that direction.

http://vimdoc.sourceforge.net/htmldoc/usr_toc.html

--
Ian Tegebo

Re: Compiling vim in mingw.

[Edward L. Fox]

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 ?

[Edward L. Fox]

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

[Edward L. Fox]

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.

[Edward L. Fox]

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: Where to find 7.1a patchlevels runtimes? (Was: patch 7.1a.001)

[A.J.Mechelynck]

Bram Moolenaar wrote:

Tony Mechelynck wrote:

[...]
I notice this patch modifies one runtime file. This reminds me that runtime 
updates are not always reflected in patches. Do the files in 
ftp://ftp.vim.org/pub/vim/runtime/ (and the equivalent rsync repository, 
ftp.nluug.nl::Vim/runtime/ ) apply to 7.0 only, or to both 7.0 and 7.1? (The 
latest changes there are for a large number of spelling dictionaries.)


They are for both.  There are no (recent) source code changes that are
required for the updated runtime files.


On thinking back, I would suspect they /aren't/ the same, since the
first line of each helpfile mentions either 7.0 or 7.1a -- so at least
the contents of the doc/ subfolders are different. So -- will runtime
upgrades for 7.1 beta be always reflected in patches, or else will
there be a runtime server -- and where?

[...]

Well, then for 7.1a I suppose I can use the same rsync command, but with 
--exclude=/doc/ in addition to --exclude=/dos/ so the new helpfiles 
(with 7.1a in the first line) won't all be replaced, and the :help 
version-7.1 section won't be deleted. This makes it (please remove spurious 
linebreaks added by my mailer or by yours, and correct me if I'm wrong)


cd ~/.build/vim/vim71a

rsync -avzcP --delete --exclude=/dos/ --exclude=/doc/ 
ftp.nluug.nl::Vim/runtime/ ./runtime/ 21 |tee rsync.log


But won't this roll back the 7.1a.001 change in autoload/spellfile.vim ?


Best regards,
Tony.
--
You can make it illegal, but you can't make it unpopular.

Re: Compiling vim in mingw.

[A.J.Mechelynck]

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).



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: Compiling vim in mingw.

[Edward L. Fox]

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