Vim 7.3a ready for beta testing
Bram Moolenaar
Hello Vim users,
Announcing: Vim (Vi IMproved) version 7.3a BETA
This is a BETA release of Vim 7.3. It consists of Vim 7.2 plus all
patches, updated runtime files and some more.
7.3a both includes lots of fixes and a few new features. Everything
needs to be tested to verify no new problems have been introduced.
Please report every problem you find! The time until a 7.3 release
depends on how many problems are reported.
The biggest additions since 7.2:
- Persistent undo
- Blowfish encryption, also encrypt the swap file
- Conceal text
- Lua interface
- Python 3 interface
Once you have installed Vim 7.3a BETA you can find details about the
changes since Vim 7.2 with:
:help version-7.3
Known problem: The MS-Windows self-installing executable sets the wrong
path for the uninstaller. You can uninstall Vim through the menu:
Start/All Programs/Vim 7.3a/Uninstall
Testing
-------
Please especially test the persistent undo and encryption. These need
to work reliably.
Report anything that isn't right. That includes a crash but also a typo
in the documentation.
Gratitude
---------
If you like Vim, this is the way to say thanks:
http://iccf-holland.org/clinic.html
Where to get it
---------------
The best way to obtain the latest Vim 7.3 is using Mercurial.
Summary:
hg clone https://vim.googlecode.com/hg/ vim
cd vim
hg update vim73
More information here: http://www.vim.org/mercurial.php
All files can be found below this directory:
ftp://ftp.vim.org/pub/vim/unstable/
Information about which files to download for what system (don't use the
links, they are still for Vim 7.2):
http://www.vim.org/download.php
A list of mirror sites can be found here:
http://www.vim.org/mirrors.php
An overview of the files below "unstable":
UNIX:
unix/vim-7.3a.tar.bz2 sources + runtime files, bzip2 compressed
MS-WINDOWS one-size-fits-all:
pc/gvim73a.exe self-installing, includes all runtime files
VARIOUS:
doc/vim73ahtml.zip help files converted to HTML
MS-WINDOWS separate files:
pc/vim73art.zip runtime files
pc/gvim73a.zip GUI binary for Windows 95/98/NT/2000/XP
pc/gvim73aole.zip GUI binary with OLE support
pc/gvim73a_s.zip GUI binary for Windows 3.1 (untested)
pc/vim73ad32.zip console version for MS-DOS/Windows 95/98
pc/vim73aw32.zip console version for Windows NT/2000/XP
pc/vim73asrc.zip sources for PC (with CR-LF)
DIFFS TO PREVIOUS RELEASE:
unix/vim-7.2-7.3a.diff.gz sources + runtime files
Omitted in this version are:
- Extra and lang archives, these are now included in the main source
and runtime archives.
- The 16-bit DOS version, I could not build it.
- OS/2 and Amiga versions, these are obsolete.
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, discuss new features 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 <vim...@vim.org>. 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!
Happy Vimming!
--
ARTHUR: Shut up! Will you shut up!
DENNIS: Ah, now we see the violence inherent in the system.
ARTHUR: Shut up!
DENNIS: Oh! Come and see the violence inherent in the system!
HELP! HELP! I'm being repressed!
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
James Vega
> The biggest additions since 7.2:
> - Persistent undo
> - Blowfish encryption, also encrypt the swap file
> - Conceal text
> - Lua interface
> - Python 3 interface
Since Vim keeps gaining support for more language interfaces, is there a
reason not to make them all dynamically loaded? This already happens on
Windows and on configure-using systems where Python 2 and Python 3
support are enabled at the same time.
I would find this quite useful from my stance as the maintainer for the
Vim packages in Debian since that would allow me to enable the language
bindings in more packages (and enable more languages) without forcing
the users to install those libraries in order for Vim to run. As it
currently stands, I don't build the mzscheme interface and don't plan to
build the lua or python3 interfaces.
If changing the language interfaces to dynamic loading is something that
would be accepted for 7.3, I'd be willing to work on the patches. I
already have a first pass at doing so for the Perl interface.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
Bram Moolenaar
James Vega wrote:
Most Unix systems already use shared libraries. That still means the
libraries need to be installed for Vim to startup, but memory use is
reduced a lot.
I'm not sure if this works everywhere. Also, it increases the chance of
runtime failure, instead of failing on startup.
I see the current dynamic loading when both Python and Python 3 are
supported an experiment. Let's see how this goes.
If you can make this work with a configure argument, it's fine to
include these changes and leave them disabled by default. For your
distribution, with a known environment, you could enable them.
--
5 out of 4 people have trouble with fractions.
James Vega
> If you can make this work with a configure argument, it's fine to
> include these changes and leave them disabled by default. For your
> distribution, with a known environment, you could enable them.
Attached patch enables dynamic loading for Perl if
--enable-perlinterp=dynamic is used. I also moved the use of
PERL_CFLAGS in src/Makefile so they're only used when compiling
if_perl.c and if_perlsfio.c.
mikeyao
The code has developed.
http://www.vim.org/scripts/script.php?script_id=2375
Bram Moolenaar
Mikeyao (?) wrote:
I haven't actually heard from someone using it.
Also, I have no idea why someone would want to write plugins in
Javascript. Perhaps because it's the only language someone knows?
--
Vi beats Emacs to death, and then again!
http://linuxtoday.com/stories/5764.html
mikeyao
interface added in 7.3. I think most programmers know javascript and
like it, it's going to mainstream.
Many web developers using vim, they know javascript well.
On Jul 21, 5:38 pm, Bram Moolenaar <B...@Moolenaar.net> wrote:
> Mikeyao (?) wrote:
> > Why not javascript interface ?
>
> > The code has developed.
> >http://www.vim.org/scripts/script.php?script_id=2375
>
> I haven't actually heard from someone using it.
>
> Also, I have no idea why someone would want to write plugins in
> Javascript. Perhaps because it's the only language someone knows?
>
> --
> Vi beats Emacs to death, and then again!
> http://linuxtoday.com/stories/5764.html
>
> /// sponsor Vim, vote for features --http://www.Vim.org/sponsor/\\\
> \\\ download, build and distribute --http://www.A-A-P.org ///
Matt Wozniski
On Wed, Jul 21, 2010 at 6:05 AM, mikeyao <yaowe...@gmail.com> wrote:
> On Jul 21, 5:38 pm, Bram Moolenaar <B...@Moolenaar.net> wrote:
>> Mikeyao (?) wrote:
>> > Why not javascript interface ?
>>
>> > The code has developed.
>> >http://www.vim.org/scripts/script.php?script_id=2375
>>
>> I haven't actually heard from someone using it.
>>
>> Also, I have no idea why someone would want to write plugins in
>> Javascript. Perhaps because it's the only language someone knows?
>
> Vim support many languages interface and I just found new lua
> interface added in 7.3. I think most programmers know javascript and
> like it, it's going to mainstream.
> Many web developers using vim, they know javascript well.
I haven't tried the JS interface patch, but I definitely would like to
see a javascript interface. I don't know Lua, TCL or Ruby (though I
intend to learn the latter one day), I don't like to use Perl or
Python for anything more than a few dozen lines, and I hate Scheme
almost as much as Lisp. Javascript is a powerful, easy to learn,
multi-paradigm language that was designed for embedding, so I think
it's a perfect fit for a Vim interface - and I personally would be
more likely to use it than any of the other interfaces.
~Matt
Yukihiro Nakadaira
if_v8 is a bit different from other if_*. It is not written as patch
for mainline.
My main goal of if_v8 plugin is to create a pluggable extension and to
find what is required and what is good way for it.
--
Yukihiro Nakadaira - yukihiro....@gmail.com
Bram Moolenaar
Mikeyao wrote:
> Vim support many languages interface and I just found new lua
> interface added in 7.3. I think most programmers know javascript and
> like it, it's going to mainstream.
> Many web developers using vim, they know javascript well.
The reason people write Javascript is because it's the only choice for
making applications run in a browser. Otherwise it's not a very good
language. I can't think of any good reason to write Vim plugins in
Javascript instead of a decent language, such as Python.
--
The Law of VIM:
For each member b of the possible behaviour space B of program P, there exists
a finite time t before which at least one user u in the total user space U of
program P will request b becomes a member of the allowed behaviour space B'
(B' <= B).
In other words: Sooner or later everyone wants everything as an option.
-- Vince Negri
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
Bram Moolenaar
James Vega wrote:
> On Mon, Jul 19, 2010 at 3:17 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> > If you can make this work with a configure argument, it's fine to
> > include these changes and leave them disabled by default. For your
> > distribution, with a known environment, you could enable them.
>
> Attached patch enables dynamic loading for Perl if
> --enable-perlinterp=dynamic is used. I also moved the use of
> PERL_CFLAGS in src/Makefile so they're only used when compiling
> if_perl.c and if_perlsfio.c.
Looks good. I tried it and it works fine for me. I had to move some
unused variables inside an #ifdef.
I suppose it will now be easy to support --enable-pythoninterp=dynamic
and --enable-python3interp=dynamic
We could wait for people to test this, but on the other hand if we want
to do the same for ruby/tcl/mzscheme we need to do it now, next week I
won't include patches like this.
--
TIM: That is not an ordinary rabbit ... 'tis the most foul cruel and
bad-tempered thing you ever set eyes on.
ROBIN: You tit. I soiled my armour I was so scared!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Christian J. Robinson
>
> We could wait for people to test this, but on the other hand if we
> want to do the same for ruby/tcl/mzscheme we need to do it now, next
> week I won't include patches like this.
It broke compiling using Make_cyg.mak for me. (Just to be sure I did
an "hg update -C".)
% hg summary
parent: 2369:454f314d0e61 tip
Make it possible to load Perl dynamically on Unix. (James Vega)
branch: vim73
commit: 4 modified, 9 unknown
update: (current)
% make -f Make_cyg.mak PERL=/cygdrive/c/strawberry/perl
DYNAMIC_PERL=yes OLE=yes FEATURES=BIG
gcc-3 -c -O3 -fomit-frame-pointer -freg-struct-return
-fno-strength-reduce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400
-D_WIN32_WINNT=0x0400 -DFEAT_PERL -DDYNAMIC_PERL
-DDYNAMIC_PERL_DLL=\"perl512.dll\" -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV
-DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE
-DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_OLE
-march=i386 -Iproto -I/cygdrive/c/strawberry/perl/lib/CORE -s
-mno-cygwin if_perl.c -o gobj/if_perl.o
if_perl.xs:101:19: dlfcn.h: No such file or directory
if_perl.xs: In function `perl_runtime_link_init':
if_perl.xs:450: error: `RTLD_LAZY' undeclared (first use in this function)
if_perl.xs:450: error: (Each undeclared identifier is reported only once
if_perl.xs:450: error: for each function it appears in.)
if_perl.xs:450: error: `RTLD_GLOBAL' undeclared (first use in this function)
if_perl.xs:450: warning: assignment makes pointer from integer without a cast
if_perl.xs:459: warning: assignment makes pointer from integer without a cast
make: *** [gobj/if_perl.o] Error 1
- Christian
--
Christian J. Robinson <hep...@gmail.com>
Tony Mechelynck
>
> James Vega wrote:
>
>> On Mon, Jul 19, 2010 at 3:17 PM, Bram Moolenaar<Br...@moolenaar.net> wrote:
>>> If you can make this work with a configure argument, it's fine to
>>> include these changes and leave them disabled by default. For your
>>> distribution, with a known environment, you could enable them.
>>
>> Attached patch enables dynamic loading for Perl if
>> --enable-perlinterp=dynamic is used. I also moved the use of
>> PERL_CFLAGS in src/Makefile so they're only used when compiling
>> if_perl.c and if_perlsfio.c.
>
> Looks good. I tried it and it works fine for me. I had to move some
> unused variables inside an #ifdef.
>
> I suppose it will now be easy to support --enable-pythoninterp=dynamic
> and --enable-python3interp=dynamic
>
> We could wait for people to test this, but on the other hand if we want
> to do the same for ruby/tcl/mzscheme we need to do it now, next week I
> won't include patches like this.
>
Hm, just for my edification, what will happen if an "older" version of
configure encounters --enable-pythoninterp=dynamic ?
treat as =yes (or empty)
treat as =no (or --disable-pythoninterp)
throw an error and stop the make at that point (or if not run by make,
exit with nonzero exitcode)
?
Best regards,
Tony.
--
"If you can count your money, you don't have a billion dollars."
-- J. Paul Getty
James Vega
<hep...@gmail.com> wrote:
> On Wed, Jul 21, 2010 at 2:08 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>>
>> We could wait for people to test this, but on the other hand if we
>> want to do the same for ruby/tcl/mzscheme we need to do it now, next
>> week I won't include patches like this.
>
> It broke compiling using Make_cyg.mak for me. (Just to be sure I did
> an "hg update -C".)
Oops. Looks like I was using the wrong "building on Windows" check.
The attached patch should fix it, as that's what the Python modules are
using.
James Vega
The configure script currently only tries to build the python/python3
interfaces if --enable-pythoninterp=yes is given (--enable-pythoninterp
with no arguments is the same as specifying =yes). Anything else is
treated as =no.
Christian J. Robinson
> On Wed, Jul 21, 2010 at 4:58 PM, Christian J. Robinson
> <hep...@gmail.com> wrote:
>> On Wed, Jul 21, 2010 at 2:08 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>>>
>>> We could wait for people to test this, but on the other hand if we
>>> want to do the same for ruby/tcl/mzscheme we need to do it now, next
>>> week I won't include patches like this.
>>
>> It broke compiling using Make_cyg.mak for me. (Just to be sure I did
>> an "hg update -C".)
>
> Oops. Looks like I was using the wrong "building on Windows" check.
> The attached patch should fix it, as that's what the Python modules are
> using.
Yes, this fixed it. Thank you.
Bram Moolenaar
James Vega wrote:
> On Wed, Jul 21, 2010 at 4:58 PM, Christian J. Robinson
> <hep...@gmail.com> wrote:
> > On Wed, Jul 21, 2010 at 2:08 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
> >>
> >> We could wait for people to test this, but on the other hand if we
> >> want to do the same for ruby/tcl/mzscheme we need to do it now, next
> >> week I won't include patches like this.
> >
> > It broke compiling using Make_cyg.mak for me. (Just to be sure I did
> > an "hg update -C".)
>
> Oops. Looks like I was using the wrong "building on Windows" check.
> The attached patch should fix it, as that's what the Python modules are
> using.
Thanks. I think using WIN3264 is a little bit better. Trying to avoid
all the different symbols that compiler define and use the one defined
in vim.h.
I have included this change now.
--
ROBIN: The what?
ARTHUR: The Holy Hand Grenade of Antioch. 'Tis one of the sacred relics
Brother Maynard always carries with him.
ALL: Yes. Of course.
ARTHUR: (shouting) Bring up the Holy Hand Grenade!
Luis Carvalho
<snip>
> I suppose it will now be easy to support --enable-pythoninterp=dynamic
> and --enable-python3interp=dynamic
>
> We could wait for people to test this, but on the other hand if we want
> to do the same for ruby/tcl/mzscheme we need to do it now, next week I
> won't include patches like this.
In the same vein, I'll attaching a patch that adds dynamic support for the Lua
interface. I won't be able to test it in Windows until next week. I'm taking
the opportunity to also patch the help file.
Cheers,
Luis
--
Computers are useless. They can only give you answers.
-- Pablo Picasso
--
Luis Carvalho (Kozure)
lua -e 'print((("lexca...@NO.gmail.SPAM.com"):gsub("(%u+%.)","")))'
björn
Dynamic loading of Perl does not work on Mac OS X. I did some digging
around and the problem is that dlopen() doesn't find "libperl.dylib".
Apparently this dylib is hidden under
/System/Library/Perl/lib/5.10/libperl.dylib
The easy fix would be to patch configure.in to include the full path
when setting DYNAMIC_PERL_DLL instead of just "libperl.dylib", but I
don't know how to get the path. Is there some "Perl-way" of doing
this? (I tried using $vi_cv_perllib but it points to the wrong
directory.)
Björn
James Vega
> Bram Moolenaar wrote:
> <snip>
> > I suppose it will now be easy to support --enable-pythoninterp=dynamic
> > and --enable-python3interp=dynamic
> >
> > We could wait for people to test this, but on the other hand if we want
> > to do the same for ruby/tcl/mzscheme we need to do it now, next week I
> > won't include patches like this.
>
> In the same vein, I'll attaching a patch that adds dynamic support for the Lua
> interface. I won't be able to test it in Windows until next week. I'm taking
> the opportunity to also patch the help file.
Attached is a patch to use the SONAME-versioned liblua, if it exists,
for dlopen. The patch also changes how the version is determined to be
more robust against future versions which are longer than 5.1, 5.0, etc.
James Vega
Bram Moolenaar
James Vega wrote:
Included, thanks.
--
Zen Microsystems: we're the om in .commmmmmmmm
Patrick Texier
message <201007182051....@masaka.moolenaar.net>�:
> Announcing: Vim (Vi IMproved) version 7.3a BETA
Thanks Bram and all working for this version. rnu is a very good idea.
I can compile with Borland C++ 5.5 / Win 98 (huge + perl).
Attached patch explains a variable for LifeLines syntax coloring.
--
Patrick Texier
Bram Moolenaar
Patrick Texier wrote:
> Le Sun, 18 Jul 2010 22:51:51 +0200, Bram Moolenaar a écrit dans le
> message <201007182051....@masaka.moolenaar.net> :
>
> > Announcing: Vim (Vi IMproved) version 7.3a BETA
>
> Thanks Bram and all working for this version. rnu is a very good idea.
> I can compile with Borland C++ 5.5 / Win 98 (huge + perl).
>
> Attached patch explains a variable for LifeLines syntax coloring.
Thanks.
Next version coming up...
--
Lawmakers made it obligatory for everybody to take at least one bath
each week -- on Saturday night.
[real standing law in Vermont, United States of America]
David Wilhelm
>
>
> Mikeyao wrote:
>
> > Vim support many languages interface and I just found new lua
> > interface added in 7.3. I think most programmers know javascript and
> > like it, it's going to mainstream.
> > Many web developers using vim, they know javascript well.
>
> The reason people write Javascript is because it's the only choice for
> making applications run in a browser. Otherwise it's not a very good
> language. I can't think of any good reason to write Vim plugins in
> Javascript instead of a decent language, such as Python.
>
I just wanted to add my support to the idea of adding Javascript bindings.
I love Vim, and I love Javascript. I would very much like to use it to write
Vim scripts. I suspect I am not alone.
Ben Fritz
On Sep 7, 10:26 pm, David Wilhelm <dewilh...@gmail.com> wrote:
> > The reason people write Javascript is because it's the only choice for
> > making applications run in a browser. Otherwise it's not a very good
> > language. I can't think of any good reason to write Vim plugins in
> > Javascript instead of a decent language, such as Python.
>
> I just wanted to add my support to the idea of adding Javascript bindings.
> I love Vim, and I love Javascript. I would very much like to use it to write
> Vim scripts. I suspect I am not alone.
UltraEdit) use Javascript or a Javascript-based language for their
scripting.
Personally, I never use scripting languages other than vimscript for
controlling Vim, and find it a hassle to install one for the sake of a
plugin. I haven't found a plugin yet which uses another scripting
language and I've wanted enough to try installing it. Of course, I
have installed fewer than a dozen plugins total, so maybe I'm not the
target audience for such plugins anyway.