Vim 7.3 released!
Bram Moolenaar
Hello Vim users,
Announcing: Vim (Vi IMproved) version 7.3
This is a minor release of Vim. It consists of Vim 7.2 plus all
patches, updated runtime files and some more, see below. It has been
two years since the 7.2 release, thus it's not that "minor". But not
"major" either. Something in between, don't know how to call that.
The most notable additions since 7.2:
- Persistent undo and undo for reload
- Blowfish encryption, encryption of the swap file
- Conceal text
- Lua interface
- Python 3 interface
Once you have installed Vim 7.3 you can find all the details about the
changes since Vim 7.2 with:
:help version-7.3
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/src
hg update vim73
make
More information here: http://www.vim.org/mercurial.php
All downloadable files can be found below this directory:
ftp://ftp.vim.org/pub/vim/
Direct link to the MS-Windows self-installing executable:
ftp://ftp.vim.org/pub/vim/pc/gvim73.exe
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
UNIX:
unix/vim-7.3.tar.bz2 sources + runtime files, bzip2 compressed
MS-WINDOWS one-size-fits-all:
pc/gvim73.exe installer for GUI and console executables,
includes all runtime files, many features
VARIOUS:
doc/vim73html.zip help files converted to HTML
MS-WINDOWS separate files:
pc/vim73rt.zip runtime files
pc/gvim73.zip GUI binary for Windows 95/98/NT/2000/XP
pc/gvim73ole.zip GUI binary with OLE support
pc/gvim73_s.zip GUI binary for Windows 3.1 (untested)
pc/vim73d32.zip console version for MS-DOS/Windows 95/98
pc/vim73w32.zip console version for Windows NT/2000/XP
pc/vim73src.zip sources for PC (with CR-LF)
DIFFS TO PREVIOUS RELEASE:
unix/vim-7.2-7.3.diff.gz sources + runtime files
unstable/unix/vim-7.3f-7.3.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, 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!
--
Q: Should I clean my house or work on Vim?
A: Whatever contains more bugs.
/// 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 ///
--
You received this message from the "vim_announce" maillist.
For more information, visit http://www.vim.org/maillist.php
Christian Brabandt
On So, 15 Aug 2010, Bram Moolenaar wrote:
> Announcing: Vim (Vi IMproved) version 7.3
[…]
I think I found an error with the Windows builds. All messages that are
given, can't be displayed correctly, when they contain umlauts:
e.g.
E474: Ung<fc>ltiges Argument
which should have been
E474: Ungültiges Argument
This did not happen with previous releases.
:lang results in
Momentane Sprache:
"LC_COLLATE=German_Germany.1252;LC_CTYPE=C;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252"
:lang mes:
Momentane messages Sprache: "de"
Did something change with regard to locales or do I now have to
configure vim to use a German locale and if so how?
regards,
Christian
Bram Moolenaar
Christian Brabandt wrote:
Nothing changed recently. I always use the same procedure when building
releases. Is this a problem with 'enc' perhaps? Make sure you don't
change 'enc', except only very early in your .vimrc.
--
From "know your smileys":
:q vi user saying, "How do I get out of this damn emacs editor?"
Christian Brabandt
On Mo, 16 Aug 2010, Bram Moolenaar wrote:
> Christian Brabandt wrote:
> > On So, 15 Aug 2010, Bram Moolenaar wrote:
> >
> > > Announcing: Vim (Vi IMproved) version 7.3
> > [�]
> >
> > I think I found an error with the Windows builds. All messages that are
> > given, can't be displayed correctly, when they contain umlauts:
> > e.g.
> > E474: Ung<fc>ltiges Argument
> > which should have been
> > E474: Ung�ltiges Argument
> >
> > This did not happen with previous releases.
> >
> > :lang results in
> >
> > Momentane Sprache:
> > "LC_COLLATE=German_Germany.1252;LC_CTYPE=C;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252"
> >
> > :lang mes:
> > Momentane messages Sprache: "de"
> >
> > Did something change with regard to locales or do I now have to
> > configure vim to use a German locale and if so how?
>
> Nothing changed recently. I always use the same procedure when building
> releases. Is this a problem with 'enc' perhaps? Make sure you don't
> change 'enc', except only very early in your .vimrc.
Thanks. That was it. I set my 'encoding' to utf-8 at the beginning of my
.vimrc. Commenting that out worked. I guess, I can't set my encoding to
utf-8 now?
I used that snipped, that I read at vim_use by Tony:
" set Unicode if possible
" First, check that the necessary capabilities are compiled-in
if has("multi_byte")
" (optional) remember the locale set by the OS
let g:locale_encoding = &encoding
" if already Unicode, no need to change it
" we assume that an encoding name is a Unicode one
" if its name starts with u or U
if &encoding !~? '^u'
" avoid clobbering the keyboard's charset
if &termencoding == ""
let &termencoding = &encoding
endif
" now we're ready to set UTF-8
"set encoding=utf-8
endif
" heuristics for use at file-open
" how are different fileencodings determined?
" This is a list. The first that succeeds, will be used
" default is 'ucs-bom,utf-8,default,latin1'
set fileencodings=ucs-bom,utf-8,latin9
" optional: defaults for new files
" disable bomb, causes sometimes problems with helptags and vimball
" setglobal bomb fileencoding=utf-8
setglobal nobomb fileencoding=utf-8
endif
Anyway, I noticed another problem. I cannot edit my .vimrc from within
gvim. When writing it, gvim simply crashes.
regards,
Christian
Philip Prindeville
checking uint32_t is 32 bits... configure: error: could not compile program using uint32_t.
Note that this error message is misleading. The program compiles just fine. It simply won't run because it's built for the wrong architecture.
Not sure if this test is even useful: if you have a <stdint.h> file you should trust it. So I would check for a program including this header file compiling, and not bother actually running it.
Philip Prindeville
> Trying to cross-compile, but this breaks:
>
> checking uint32_t is 32 bits... configure: error: could not compile program using uint32_t.
>
> Note that this error message is misleading. The program compiles just fine. It simply won't run because it's built for the wrong architecture.
>
> Not sure if this test is even useful: if you have a <stdint.h> file you should trust it. So I would check for a program including this header file compiling, and not bother actually running it.
Using the following patch. The assumption being that you have to trust your <stdint.h> file by necessity, and if it's wrong then a whole cacastorm of badness will be unleashed and you won't need vim's configure to tell you so.
Christian Brabandt
On Mo, 16 Aug 2010, Christian Brabandt wrote:
> Anyway, I noticed another problem. I cannot edit my .vimrc from within
> gvim. When writing it, gvim simply crashes.
I found the problem. It can be reproduced on Windows using this
commandline:
gvim -u NONE -U NONE -N -c "echo strftime('%a %Y\-%m\-%d %R')"
regards,
Christian
Benjamin R. Haskell
I've got either another data point or just a more minimal example that
fails here under Win7:
gvim -u NONE -N -c "echo strftime('%R')"
I thought the weird quoting was key, based on your example, but it
appears the '%R' is all I needed. '%T' also triggers it for me.
(And the -U NONE is unnecessary, because -u NONE disables gvimrc, too
[learned that on-list a short while back]).
gvim --version: (typing by hand -- can't copy-paste from Message boxes):
Vim 7.3e BETA
MS-Win 32-bit w/ OLE support
Compiled by Bram@KIBAALE
Big version with GUI.
(Possibly of note is that it's 64-bit Windows.)
Haven't installed 7.3 proper yet.
--
Best,
Ben
Bram Moolenaar
Philip Prindeville wrote:
> Trying to cross-compile, but this breaks:
>
> checking uint32_t is 32 bits... configure: error: could not compile
> program using uint32_t.
Sorry to hear that. This check was there for a while, I wonder why it
took so long to discover this problem.
> Note that this error message is misleading. The program compiles just
> fine. It simply won't run because it's built for the wrong
> architecture.
>
> Not sure if this test is even useful: if you have a <stdint.h> file
> you should trust it. So I would check for a program including this
> header file compiling, and not bother actually running it.
Many systems don't have stdint.h, it's a recent addition from C99.
I consider C89 _the_ C language. C99 is a mix of good things and a few
bad choices. Especially that the semantics of strings depends on the
environment.
We had problems figuring out the type to use for 32 bit ints, that's why
this check was added.
Is't there a way to say "skip this when cross-compiling"?
--
From "know your smileys":
:'-D Laughing so much that they're crying
Bram Moolenaar
Christian Brabandt wrote:
Thanks for figuring that out. Perhaps someone knows how to fix it?
Which gvim version is this with?
--
From "know your smileys":
:-D Big smile
Antonio Giovanni Colombo
>> gvim -u NONE -U NONE -N -c "echo strftime('%a %Y\-%m\-%d %R')"
>
> Which gvim version is this with?
With the distributed gvim 7.3 invoked from MS-DOS (in Windows XP),
I get the error.
AppName: gvim.exe AppVer: 7.3.277.0 ModName: gvim.exe
ModVer: 7.3.277.0 Offset: 00004a1d
and a lot of further info which I will not put here. If needed they
can be sent to the interested people.
Antonio
--
/||\ | Antonio Colombo
/ || \ | ant...@geekcorp.com
/ () \ | azc...@gmail.com
(___||___) | az...@yahoo.com
Christian Brabandt
On Mi, 18 Aug 2010, Bram Moolenaar wrote:
>
> Christian Brabandt wrote:
>
> > On Mo, 16 Aug 2010, Christian Brabandt wrote:
> >
> > > Anyway, I noticed another problem. I cannot edit my .vimrc from within
> > > gvim. When writing it, gvim simply crashes.
> >
> > I found the problem. It can be reproduced on Windows using this
> > commandline:
> >
> > gvim -u NONE -U NONE -N -c "echo strftime('%a %Y\-%m\-%d %R')"
>
> Thanks for figuring that out. Perhaps someone knows how to fix it?
> Which gvim version is this with?
As Benjamin said, it's %R and also %T that triggers it. My environment
is 32bit WinXP using the official built gvim73.exe from www.vim.org.
BTW: a self compiled mingw-Version does not crash. It simply returns the
empty string for %R and %T
regards,
Christian
Benjamin R. Haskell
Via the PHP caveats on strftime (non-)portability[1] that specifically
mentioned %T and %R on Windows, I also found that %e and %D crash Vim.
This seems to just be due to bad strftime() error-handling
characteristics. '%0', '%.', and '%-' also crash it (probably any
invalid format specifiers).
Full list of valid format specifiers for the strftime provided by Visual
Studio 2010 is at [2], if it's useful for debugging.
--
Best,
Ben
[1] http://www.php.net/manual/en/function.strftime.php
[2] http://msdn.microsoft.com/en-us/library/fe06s4ak.aspx
Mike Williams
It is by design in the recent VC CRT libraries (VS2005 onwards?) Any
unsupported format specifier will result in a crash. On Windows, or at
least builds that use recent VC CRT libraries, VIM needs to validate the
format string that it only contains supported format specifiers. I'm
guessing mingw is using older versions of the Windows CRT or has its own
version.
TTFN
Mike
--
Dose anyone half a spill cheker?
Andy Wokula
Mike Williams
Attached is a patch to check for allowed specifiers for Windows. Not
sure if any other platforms need a similar check (I doubt it). Don't
know if need extra code to cope with multi-byte format strings. Don't
know if having the check function in eval.c is the right thing to do.
Does stop the crash for me.
Have at it.
Sergey Khorev
>> unsupported format specifier will result in a crash. On Windows, or at
>> least builds that use recent VC CRT libraries, VIM needs to validate the
>> format string that it only contains supported format specifiers. I'm
>> guessing mingw is using older versions of the Windows CRT or has its own
>> version.
>
> Attached is a patch to check for allowed specifiers for Windows. Not sure
> if any other platforms need a similar check (I doubt it). Don't know if
> need extra code to cope with multi-byte format strings. Don't know if
> having the check function in eval.c is the right thing to do. Does stop the
> crash for me.
Perhaps another options would be installation of custom validation
handler via _set_invalid_parameter_handler as described on
http://msdn.microsoft.com/en-us/library/ksazx244(v=VS.80).aspx
Unfortunately I cannot provide a patch at the moment. Maybe later if
no one outruns me.
Benjamin R. Haskell
It seems like a more-robust version of the patch already sent would be
to double the '%'s that precede invalid format specifiers (so the
strftime call still succeeds, it just wouldn't properly substitute the
ones it can't).
The _set_invalid_parameter_handler approach might be simpler if the goal
is to just fail on invalid input. (No need for Vim to check the input.)
Seems more maintainable than reïmplementing the parsing portion of strftime.
At the bottom of the slippery slope (that input-checking starts down),
duplicating the entirety of strftime would allow non-strftime systems to
have the functionality.
--
Best,
Ben
Bram Moolenaar
Mike Williams wrote:
And what is the function provided to check for a valid format?
--
From "know your smileys":
:-F Bucktoothed vampire with one tooth missing
Mike Williams
;-) Forcing a crash on an unsuspecting development team is most likely
preferable to providing a security hole through silent unknown
behaviour. A quick google shows a number of major FOSS projects falling
over this issue.
Mike
--
Adversity makes men, and prosperity makes monsters.
Bram Moolenaar
Mike Williams wrote:
Should we reset the bad_param_handler after invoking strftime()?
We should at least give an error message in the handler. And set
a flag that it failed.
--
I AM THANKFUL...
...for the mess to clean after a party because it means I have
been surrounded by friends.
Mike Williams
>
> Mike Williams wrote:
>
>> On 18/08/2010 18:54, Sergey Khorev wrote:
>>>>> It is by design in the recent VC CRT libraries (VS2005 onwards?) Any
>>>>> unsupported format specifier will result in a crash. On Windows, or at
>>>>> least builds that use recent VC CRT libraries, VIM needs to validate the
>>>>> format string that it only contains supported format specifiers. I'm
>>>>> guessing mingw is using older versions of the Windows CRT or has its own
>>>>> version.
>>>>
>>>> Attached is a patch to check for allowed specifiers for Windows. Not sure
>>>> if any other platforms need a similar check (I doubt it). Don't know if
>>>> need extra code to cope with multi-byte format strings. Don't know if
>>>> having the check function in eval.c is the right thing to do. Does stop the
>>>> crash for me.
>>>
>>> Perhaps another options would be installation of custom validation
>>> handler via _set_invalid_parameter_handler as described on
>>> http://msdn.microsoft.com/en-us/library/ksazx244(v=VS.80).aspx
>>>
>>> Unfortunately I cannot provide a patch at the moment. Maybe later if
>>> no one outruns me.
>>
>> F1rst! :-)
>>
>> Pros: All Windows specific code.
>> Cons: Can't do anything clever with an invalid format string.
>>
>> Should be ok with mingw32.
>
> Should we reset the bad_param_handler after invoking strftime()?
I see no benefit in doing this. The function has no function other than
preventing a hard crash by the CRT. Other CRT functions may provoke a
crash with invalid parameters. It adds complexity in having to have
mch_handler_on/off() around the call to strftime(). What do you feel we
miss/gain by resetting the handler?
> We should at least give an error message in the handler. And set
> a flag that it failed.
Failure of strftime is indicated by it returning a length of 0 (assuming
the format string is not zero length) as well as setting errno. What
would having yet another flag (in Windows only builds) achieve? Note
that running in a debug build will cause warning dialogs to appear with
invalid parameters so you haven't lost a means of automatically having
the problem flagged! How many people actually run a debug build of VIM
to pick up these additional checks and warnings? (I must admit I don't).
Mike Williams
> On Wed, 18 Aug 2010, Sergey Khorev wrote:
>
>>>> It is by design in the recent VC CRT libraries (VS2005 onwards?)
>>>> Any unsupported format specifier will result in a crash. On
>>>> Windows, or at least builds that use recent VC CRT libraries, VIM
>>>> needs to validate the format string that it only contains supported
>>>> format specifiers. I'm guessing mingw is using older versions of
>>>> the Windows CRT or has its own version.
>>>
>>> Attached is a patch to check for allowed specifiers for Windows.
>>> Not sure if any other platforms need a similar check (I doubt it).
>>> Don't know if need extra code to cope with multi-byte format
>>> strings. Don't know if having the check function in eval.c is the
>>> right thing to do. Does stop the crash for me.
>>
>> Perhaps another options would be installation of custom validation
>> handler via _set_invalid_parameter_handler as described on
>> http://msdn.microsoft.com/en-us/library/ksazx244(v=VS.80).aspx
>>
>> Unfortunately I cannot provide a patch at the moment. Maybe later if
>> no one outruns me.
>
> It seems like a more-robust version of the patch already sent would be
> to double the '%'s that precede invalid format specifiers (so the
> strftime call still succeeds, it just wouldn't properly substitute the
> ones it can't).
Degrees of failing. There is a school of thought that if you are gonna
fail, fail in a really obvious way. Such as crashing? ;-)
> The _set_invalid_parameter_handler approach might be simpler if the goal
> is to just fail on invalid input. (No need for Vim to check the input.)
> Seems more maintainable than re�mplementing the parsing portion of strftime.
Indeed - smaller, simpler, localised.
> At the bottom of the slippery slope (that input-checking starts down),
> duplicating the entirety of strftime would allow non-strftime systems to
> have the functionality.
Really don't want to do that due to the locale handling. And then
someone suggests adding features for systems that don't support what
their preferred extension is. I think there is far more useful things
to work on than extending how to format date and time across multiple
platforms.
2ps worth.
Sergey Khorev
>
> Pros: All Windows specific code.
> Cons: Can't do anything clever with an invalid format string.
>
> Should be ok with mingw32.
Wow, so quick :)
I think you've done it right by installing the handler once and for
all. For users of ancient compilers I suggest to add something like:
#if (defined(__MINGW32__) || defined (__CYGWIN32__)) &&
__MSVCRT_VERSION__ >= 0x800 \
|| defined(_MSC_VER) && _MSC_VER >= 1400
Mike Williams
Works for me. Checked with VC6 which does not have the invalid param
handler. I tidied it up for potential ambiguity and reworked the patch
- see attached. Using macros for the function calls removes the needs
for duplicating the complex conditional or introducing another symbol
for later conditional compilation. I commend to the house.
TTFN
Mike
--
Words are not food, though sometimes we must eat them.
Ben Fritz
On Aug 19, 8:47 am, Mike Williams <mike.willi...@globalgraphics.com>
wrote:
> Degrees of failing. There is a school of thought that if you are gonna
> fail, fail in a really obvious way. Such as crashing? ;-)
>
important data with no warning, crashing is a very bad way to handle
anything.
Mike Williams
Alternatively you could have creeping silent corruption of the data over
a long enough time that a good version no longer exists in your backups
- you do keep backups don't you? ;-) For a product with
important/safety critical requirements I would hope it would have more
complete testing to find such crashes.
I assume VIM has the usual FOSS disclaimer about having no warranty of
merchantability or fitness for purpose. Hmm, can't find one, oh well.
As a means for MS to point out to developers possible security holes it
works wonders. The developer has to make a conscious decision on how to
handle the problem. The compiler can warn on the use of unsafe runtime
library functions but they are turned off in VIM since a decision was
made to continue using them. Usually the problem is not with how I use
the functions, but how other developers use it. ;-)
In a similar vein to how few (if any) run a debug build of VIM I would
imagine most development and testing is concentrated on working with
good input. Few developers spend much time on testing with bad input.
This becomes more difficult with multi-platform functionality as few
will have access to more than 2 or 3, and behaviour can also differ
based on compilers used. Just because it works on platform 1 does not
mean it will work on platform 2. How many different compilers and
compiler versions are used to build for Windows? Let alone the myriad
versions and variants of Unix and their C compilers. You start to
understand why there are such things as the APR library.
A key skill for any developer is not just knowing how to solve the
problem, but also how to handle bad data. If they are using a library
then they are responsible for checking how that library will cope and
deal with any problems it may have.
strftime() is a great example as it is a function that is (most likely)
supported on all platforms but they will have different behaviour with a
bad format specifier, as well as supporting their own particular
extensions. This means any user wishing to port say a .gvimrc file
across platforms is liable to have a few surprises. I doubt we want to
document the peculiarities of every platform so does it make sense to
restrict its use to say the lowest common denominator or the original
ANSI C functionality?
TTFN
Mike
--
Among my most prized possessions are words that I have never spoken.
Sergey Khorev
> handler. I tidied it up for potential ambiguity and reworked the patch -
> see attached. Using macros for the function calls removes the needs for
> duplicating the complex conditional or introducing another symbol for later
> conditional compilation. I commend to the house.
Cool stuff!!!