On 31/10/12 08:04, Axel wrote:
I think the fact that this behavior is not evident in the original (release) version of gvim (7.3.046) demonstrates that this is a bug.
It should be possible (but a lot of work) to determine a "last good" and a "first bad" version by binary search (dichotomy) and experiment, maybe with the help of with the W32 versions of gvim at http://sourceforge.net/projects/cream/files/Vim/ — where the last version seems mislabeled: it says 6.3.709 on the list of versions but it offers gvim-7-3-709.exe and gvim-7-3-709_release-notes.txt for downloading.
The procedure is as follows: You already have a "known good" (7.3.046) and a "known bad" (7.3.712). Try a version somewhere between them. If it is "good" you have a later "known good"; if it is bad, an earlier "known bad", so in either case you've narrowed the error range a bit. Try again until you find the "last good" and the "first bad" and they are as close as possible to each other. This would help find when the regression crept in.
Best regards, Tony. -- Life is a gift, living is an art. (Bram Moolenaar) -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
