7.3.001 missing 7.3.002 duplicated
Hi, Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't see 7.3.001 anywhere. At first I suspected only the commit messages were wrong but it looks like 7.3.002 really has been applied twice. Björn -- 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
Re: 7.3.001 missing 7.3.002 duplicated
On Tue, Aug 17, 2010 at 11:03 AM, björn wrote: Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't see 7.3.001 anywhere. At first I suspected only the commit messages were wrong but it looks like 7.3.002 really has been applied twice. The changes are different: vim-hg-working$ hg extdiff -c fde086181841 -p diff -o -qr Files vim-hg-working.f0915ae869cf/src/ex_docmd.c and vim-hg-working.fde086181841/src/ex_docmd.c differ Files vim-hg-working.f0915ae869cf/src/version.c and vim-hg-working.fde086181841/src/version.c differ vim-hg-working$ hg extdiff -c f0915ae869cf -p diff -o -qr Files vim-hg-working.2a2ad267db08/src/misc1.c and vim-hg-working.f0915ae869cf/src/misc1.c differ Files vim-hg-working.2a2ad267db08/src/version.c and vim-hg-working.f0915ae869cf/src/version.c differ Xavier -- 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
Re: 7.3.001 missing 7.3.002 duplicated
Björn Winckler wrote:
Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't
see 7.3.001 anywhere. At first I suspected only the commit messages
were wrong but it looks like 7.3.002 really has been applied twice.
Where do you see this?
When I look online, the version.c clearly has both 1 and 2 in
included_patches[].
http://code.google.com/p/vim/source/browse/src/version.c#715
--
From know your smileys:
:-{Worf (Never smiles anyways, so he's a bad smiley)
/// Bram Moolenaar -- b...@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_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
Re: 7.3.001 missing 7.3.002 duplicated
On 17 August 2010 12:27, Bram Moolenaar wrote: Björn Winckler wrote: Looking at the Mercurial repo I see 7.3.002 applied twice, but I can't see 7.3.001 anywhere. At first I suspected only the commit messages were wrong but it looks like 7.3.002 really has been applied twice. Where do you see this? When I look online, the version.c clearly has both 1 and 2 in included_patches[]. http://code.google.com/p/vim/source/browse/src/version.c#715 Sorry, they are indeed different...I was being lazy: after seeing that both patches touched the same files and did the exact number of changes in each file I mistakenly assumed that the patches were identical. Turned out that was just coincidence. Björn -- 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
Re: 7.3.001 missing 7.3.002 duplicated
On Tue, Aug 17, 2010 at 12:05 PM, Xavier de Gaye wrote: On Tue, Aug 17, 2010 at 11:03 AM, björn wrote: The changes are different: vim-hg-working$ hg extdiff -c fde086181841 -p diff -o -qr Files vim-hg-working.f0915ae869cf/src/ex_docmd.c and vim-hg-working.fde086181841/src/ex_docmd.c differ Files vim-hg-working.f0915ae869cf/src/version.c and vim-hg-working.fde086181841/src/version.c differ vim-hg-working$ hg extdiff -c f0915ae869cf -p diff -o -qr Files vim-hg-working.2a2ad267db08/src/misc1.c and vim-hg-working.f0915ae869cf/src/misc1.c differ Files vim-hg-working.2a2ad267db08/src/version.c and vim-hg-working.f0915ae869cf/src/version.c differ One may also use extdiff and the brilliant DirDiff Vim plugin, to display the changes between two revisions in a 3 windows Vim instance: the bottom window lists the changed files and is used to select the current file the other two windows display the changes of the selected file as a vimdiff The command for seeing the changes in 7.3.002 with the above extension is: hg vimdiff -c tip The documentation on this extension is at: http://mercurial.selenic.com/wiki/ExtdiffExtension Installation: fetch the DirDiff plugin: wget http://www.vim.org/scripts/download_script.php?src_id=5306 -O ~/.vim/plugin/DirDiff.vim edit ~/.hgrc: [extensions] hgext.extdiff = [extdiff] cmd.vimdiff = gvim opts.vimdiff = -f '+next' '+execute DirDiff argv(0) argv(1)' Xavier -- 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
Be careful on next pull from Git repo
Hi, This message is intended for those who are pulling from the Git mirror of the Mercurial repository that I am maintaining [1]. Due to how the Mercurial vim73 branch was forcibly renamed to be the default branch you need to be careful when next updating your Git clone. If you try git pull you'll get merge conflicts! If you have _no_ local changes this is how to update: $ git checkout master $ git fetch origin $ git reset --hard origin/master The master branch will now be tracking the latest changesets from the Mercurial default branch. (If you accidentally did a git pull you'll get lots of merge conflicts because Git will try to merge the latest Mercurial changeset [i.e. patch 7.3.002] into the vim72 branch. No good! If you already did git pull, then git reset --hard origin/master will put things right.) If you have local changes based off the hg/vim73 branch, then I'd suggest you update master as above and then rebase your changes on top of master afterwards. If you have made changes in your master branch (you shouldn't have!) then I'd suggest you create a new branch (git checkout -b mystuff master), do the above, then cherry-pick the commits back. You only need to do this once. The next time you update you can use git pull as usual. Björn [1] http://github.com/b4winckler/vim -- 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
Re: Plans for Mercurial branches?
On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote: Xavier de Gaye wrote: The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). ... Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. Assume that on doing the first branching last may, the reverse had been done instead, that is: . the vim73 release is developed on the main branch (the 'default' NamedBranch) . creation of a 'vim72' NamedBranch where the critical patches of the main branch (the 'default' NamedBranch) are retrofited as vim72 patches . the 'vim73' NamedBranch does not exist What would have changed: . no need to 'hg update vim73' when the branch was created (as most of us probably did at this time) . no need to 'hg update default' now (without forgetting to do first a 'hg pull'), once the vim73 release is done What are the drawbacks of the above scheme ? Xavier -- 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
Re: Plans for Mercurial branches?
On 17 August 2010 13:11, Xavier de Gaye wrote: On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote: Xavier de Gaye wrote: The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). ... Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. Assume that on doing the first branching last may, the reverse had been done instead, that is: . the vim73 release is developed on the main branch (the 'default' NamedBranch) . creation of a 'vim72' NamedBranch where the critical patches of the main branch (the 'default' NamedBranch) are retrofited as vim72 patches . the 'vim73' NamedBranch does not exist What would have changed: . no need to 'hg update vim73' when the branch was created (as most of us probably did at this time) . no need to 'hg update default' now (without forgetting to do first a 'hg pull'), once the vim73 release is done What are the drawbacks of the above scheme ? It would have made life easier for me with maintaining the Git repository. Renaming the vim73 branch default lead to problems as I outlined in a recent post. Had the development of vim73 taken place on the default branch I would have had no problems. I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). Björn -- 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
Re: RFC: use hunspell dictionaries
On Aug 16, 4:20 am, James Vega james...@jamessan.com wrote: Personally, I like the idea of using existing spell-checking libraries and had spent some time working on allowing the use of libenchant[0] instead. I wasn't able to get around to finishing it, but it's still on my list of ideas to revisit. I went with enchant instead of directly using hunspell since enchant seems to provide the capability for better spell-checking across all languages due to being able to use different spell-checkers for different languages. Hi James, Thanks for the input and sorry for the original double post, I didn't get the list sign-up just right :) Are there any other opinions on the best way to accomplish this? Is there any other work being done? Cheers, Brad -- 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
Re: vim.org without www
www is deprecated please check out http://no-www.org/ On 08/17/2010 03:25 PM, Stefan `Sec` Zehl wrote: Hi, On Sun, Aug 15, 2010 at 14:06 -0700, Sergey Avseyev wrote: Do you know why vim website doesn't respond to 'http://vim.org'? and responds only 'http://www.vim.org' Yes. This is by design. Its a bad habit to omit the www. part if you intend to talk to a webserver. Maybe call me an old fart, but you are connecting to a webserver, not a domain, and the URL you use should reflect that. CU, Sec -- Best regards, Sergey Avseyev -- 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
Patch 7.3.003
Patch 7.1.003
Problem:Crash with specific BufWritePost autocmd. (Peter Odding)
Solution: Don't free the quickfix title twice. (Lech Lorens)
Files: src/quickfix.c
*** ../vim-7.3.002/src/quickfix.c 2010-08-15 21:57:26.0 +0200
--- src/quickfix.c 2010-08-16 21:15:44.0 +0200
***
*** 2125,2130
--- 2125,2131
--qi-qf_lists[idx].qf_count;
}
vim_free(qi-qf_lists[idx].qf_title);
+ qi-qf_lists[idx].qf_title = NULL;
}
/*
*** ../vim-7.3.002/src/version.c2010-08-16 22:33:55.0 +0200
--- src/version.c 2010-08-17 20:23:05.0 +0200
***
*** 716,717
--- 716,719
{ /* Add new patch number below this line */
+ /**/
+ 3,
/**/
--
From know your smileys:
:-XMy lips are sealed
/// Bram Moolenaar -- b...@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_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
Re: Gvim + Win7 + dual monitors
Michael Wookey wrote: [cross posting from vim_use to vim_dev...sorry] On 17 August 2010 10:05, Michael Wookey michaelwoo...@gmail.com wrote: On 17 August 2010 09:08, George V. Reilly geo...@reilly.org wrote: On Mon, Aug 16, 2010 at 3:18 PM, Eric Tetz erict...@gmail.com wrote: I'm trying to use Vim in a dual monitor setup under Windows 7. If I put Vim on my secondary monitor, it snaps back to my primary monitor every time I change buffers. Anybody else experience this, and is there a way to fix it? GVim works fine on a 3-monitor Windows 7 setup for me, on any of the monitors. Does it repro if you run with -u NONE? If not, then it's one of your plugins. I can reproduce this with -u NONE. It depends on the monitor layout. I have my primary monitor on the right and the secondary monitor on the left. With gvim started on the primary (right) monitor I'll drag it to the secondary (left) monitor. Then issue a :vsplit. gvim will jump to the primary (right) monitor. The same can be seen when changing the guifont (set gfn=*). The bug is due to the negative coordinates of the secondary monitor. A good place to start debugging would be from gui_set_shellsize(). The attached patch fixes the immediate problem however it likely introduces other bugs. The problem is that gui_set_shellsize() calls gui_w32.c:gui_mch_set_shellsize() which clamps horizontal and vertical coordinates that are less than zero, to zero. The attached patch just removes the less than zero test. Consider the patch more of an RFC. Maybe someone can think of a better solution. Is there a function to ask the system what the valid coordinates are? Simply removing these lines will mean that resizing may result in the gvim window being outside of the screen boundaries on a single monitor. -- % cat /usr/include/life.h void life(void); /// Bram Moolenaar -- b...@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_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
Re: Plans for Mercurial branches?
Björn Winckler wrote: On 17 August 2010 13:11, Xavier de Gaye wrote: On Mon, Aug 16, 2010 at 7:01 PM, Bram Moolenaar wrote: Xavier de Gaye wrote: The 'vim73' branch can be given the name of the 'default' branch with the 'hg branch --force default' command after the 'default' branch is named 'vim72' with the 'hg branch vim72' command (both followed by commit). ... Now that I'm ready to make vim73 the default branch, it occurs to me that when I do this, doing hg update vim73 will stop working. Assume that on doing the first branching last may, the reverse had been done instead, that is: . the vim73 release is developed on the main branch (the 'default' NamedBranch) . creation of a 'vim72' NamedBranch where the critical patches of the main branch (the 'default' NamedBranch) are retrofited as vim72 patches . the 'vim73' NamedBranch does not exist What would have changed: . no need to 'hg update vim73' when the branch was created (as most of us probably did at this time) . no need to 'hg update default' now (without forgetting to do first a 'hg pull'), once the vim73 release is done What are the drawbacks of the above scheme ? It would have made life easier for me with maintaining the Git repository. Renaming the vim73 branch default lead to problems as I outlined in a recent post. Had the development of vim73 taken place on the default branch I would have had no problems. I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). In my opinion the default branch should contain the stable version. Most users would sync there once in a while to update their Vim. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. -- From know your smileys: %-)After staring at screen for 15 hours /// Bram Moolenaar -- b...@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_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
Re: Plans for Mercurial branches?
On Tue, Aug 17, 2010 at 5:26 PM, Bram Moolenaar wrote: Björn Winckler wrote: I for one would be very happy if the next version (vim74?) used this scheme (i.e. where all new work happens on the default branch). In my opinion the default branch should contain the stable version. Most users would sync there once in a while to update their Vim. Most users don't get their vim from source control at all - they get it from binaries or source provided by their distro. Developers would want to get the bleeding edge version, and we can assume the can follow the instructions to sync to a different branch. I think what would normally happen is to merge the development branch back into the default branch. But just like the problems you have now, I suspect that migth not work very well. Keep in mind that in most opensource projects work that way - I don't think I've ever checked out code where the starting branch wasn't the main development branch. If you want an older version, it's easy to check out an old tag. With CVS or SVN, you'd always get the latest HEAD, there's no reason for Hg to be any different. Just my $0.02 ~Matt -- 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
Re: Vim 7.3 released!
On Tue, 17 Aug 2010, Christian Brabandt wrote:
Hi Bram!
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')
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 b...@kibaale
Big version with GUI.
(Possibly of note is that it's 64-bit Windows.)
Haven't installed 7.3 proper yet.
--
Best,
Ben
--
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
Re: Vim 7.3 released!
Hi everybody,
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.exeAppVer: 7.3.277.0 ModName: gvim.exe
ModVer: 7.3.277.0Offset: 4a1d
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
/ || \ | anto...@geekcorp.com
/ () \ | azc...@gmail.com
(___||___) | az...@yahoo.com
--
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
Warning: out of range subscript in version.c (in dead code IIUC)
version.c: In function ‘intro_message’:
version.c:1273:7: warning: array subscript is above array bounds
The incriminated line is the test on mediumVersion[4] near the middle of
if (add_version)
{
STRCPY(vers, mediumVersion);
if (highest_patch())
{
/* Check for 9.9x or 9.9xx, alpha/beta version */
if (isalpha((int)mediumVersion[3]))
{
if (isalpha((int)mediumVersion[4]))
sprintf((char *)vers + 5, .%d%s, highest_patch(),
mediumVersion + 5);
else
sprintf((char *)vers + 4, .%d%s, highest_patch(),
mediumVersion + 4);
}
else
sprintf((char *)vers + 3, .%d, highest_patch());
}
col += (int)STRLEN(vers);
}
in this case (see version.c:31 and version.h:38) mediumVersion is 7.3,
so IIUC mediumVersion[3] is the end-of-string null and mediumVersion[4]
is whatever comes after that in memory. But since a null byte is not
alphabetic, isalpha((int)mediumVersion[3]) is FALSE and the warning is
in dead code.
Please check the above analysis, my knowledge of C language syntax is
half-forgotten, and it was sketchy to begin with. In particular I'm
assuming that the (int) typecast will sign-extend or zero-extend the
char value to an int, but I'm not at all sure that the compiler won't
instead take as many bytes as can make up an int from the address
pointed to.
Best regards,
Tony.
--
A reading from the Book of Armaments, Chapter 4, Verses 16 to 20:
Then did he raise on high the Holy Hand Grenade of Antioch, saying,
Bless this, O Lord, that with it thou mayst blow thine enemies to tiny
bits, in thy mercy. And the people did rejoice and did feast upon the
lambs and toads and tree-sloths and fruit-bats and orangutans and
breakfast cereals ... Now did the Lord say, First thou pullest the
Holy Pin. Then thou must count to three. Three shall be the number of
the counting and the number of the counting shall be three. Four shalt
thou not count, neither shalt thou count two, excepting that thou then
proceedeth to three. Five is right out. Once the number three, being
the number of the counting, be reached, then lobbest thou the Holy Hand
Grenade in the direction of thine foe, who, being naughty in my sight,
shall snuff it.
-- Monty Python, Monty Python and the Holy Grail
--
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
Re: motif vim73 on macosx X11: clipboard/primary selection not working across windows
Lech Lorens wrote: On 16-Aug-2010 Peter Odding pe...@peterodding.com wrote: Lech Lorens wrote: Recently I've also been having lots of problems with pasting into/from Vim. So far I haven't figured out what it is that makes pasting sometimes fail, but it happens to me frequently. If I am not mistaken, if an instance of Vim is having problems with pasting, it doesn't get better; the only solution is to close Vim and start a new instance. Are you referring to a specific platform or GUI version of Vim? Because I've been getting annoyed with GVim 7.3 on GTK (Linux) apparently losing my paste buffer. One complication in my setup is that I'm running VirtualBox with clipboard integration enabled and while this is a great feature when it works, it also seems to eat my paste buffer once in a while... - Peter Odding Ah, how could I have forgotten to mention that I'm using Vim 7.3 with Athena GUI on Linux. The thing that deceived me at first is that I recently changed my window manager from Fluxbox under Gnome to Awesome. But if more people are having problems, maybe Vim is to blame. -- Cheers, Lech for me (from the original report), vim definitely looks like the culprit. i'm using macosx-10.6.4, motif (from macports) and the X11 that comes with macosx (and a recent version of xquartz-2.5.2) and twm. given that fixed setup, vim-7.3 can't copy/paste but vim-7.2.446 can. i'm just having another look at the behaviour which seems to be: on starting gvim, you can copy from other windows and paste into gvim's window multiple times. however, as soon as you select any text in the gvim window it no longer sees any text selections that have happened in other windows, nor do other windows see any selections that have been made in gvim. so as soon as you select text in gvim, it becomes isolated from the system's primary selection and just operates with its own local one. so it looks like this behaviour applies to linux and macosx and to gtk, athena and motif but it obviously can't be happening for everyone or it would never have survived this far. i hope this helps someone find the cause of the problem. cheers, raf -- 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
Re: motif vim73 on macosx X11: clipboard/primary selection not working across windows
On 18-Aug-2010 raf r...@raf.org wrote: for me (from the original report), vim definitely looks like the culprit. i'm using macosx-10.6.4, motif (from macports) and the X11 that comes with macosx (and a recent version of xquartz-2.5.2) and twm. given that fixed setup, vim-7.3 can't copy/paste but vim-7.2.446 can. i'm just having another look at the behaviour which seems to be: on starting gvim, you can copy from other windows and paste into gvim's window multiple times. however, as soon as you select any text in the gvim window it no longer sees any text selections that have happened in other windows, nor do other windows see any selections that have been made in gvim. so as soon as you select text in gvim, it becomes isolated from the system's primary selection and just operates with its own local one. so it looks like this behaviour applies to linux and macosx and to gtk, athena and motif but it obviously can't be happening for everyone or it would never have survived this far. i hope this helps someone find the cause of the problem. cheers, raf OK, so for me pasting into Gvim is broken by the changeset which has the message Fixes for time in clipboard request. Also fix ownership. (David Fries). (Sorry for no changeset ID - I'm using a git clone of the Vim Mercurial repo, which gives me different commit IDs). What might be worth mentioning is even once using the primary selection becomes broken, it is still possible to read the clipboard. However, reading the clipboard takes awfully long - I tried pasting 3 lines, 100 bytes of text into Gvim and it took about 3 seconds to complete. -- Cheers, Lech -- 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
Cscope quickfix -- not jump to first error
Earlier this year, Sergey Khorev posted a patch to all csqf to support bang arguments. The bang arguments would prevent the cscope query from automatically jumping to the first result. I was hoping this patch made it into 7.3, but it doesn't look to have made it. Is it possible to bring that patch in soon? Thanks! Luke -- 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
RE: Removing vim-patches included in Vim 7.3
Xavier de Gaye wrote: As there won't be a vimGdb patch for vim73, can you please also remove: 6. vimGdb I have updated the patches list: http://groups.google.com/group/vim_dev/web/vim-patches I added a brief intro to say that some patches are no longer listed because they are in Vim 7.3. These patches were removed (source code is now in Vim 7.3): Persistent undo Lua Interface vimGdb Additional floating-point functions Relative line numbers Conceal (in-line folding), ownsyntax and cursorbind John -- 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
