Re: EOL for Cygwin - Win32 cross compiles
On Mar 8 03:05, Tony Mechelynck wrote: To compile a cygwin build which does require the cygwin1.dll to run, use the top-level Makefile and have it run configure (if it works, I haven't tested it). I'm the vim maintainer for the Cygwin distribution. I'm building the vim package for the Cygwin distro is build using the top-level configure all the time. It works OOTB for at least the last 8 years. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Mar 7 20:35, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 12:35 PM, Tony Mechelynck wrote: That's if you want Vim for Cygwin. You can also use Cygwin to compile (cross-compile, if you want) versions of Vim which don't need Cygwin to run, as explained on my Windows HowTo Hm. Support for using cygwin's gcc to do cross-compile builds is soon to be dropped. Maybe we should remove the option to do this from Make_cyg.mak? Or, at least add a note to the README noting that the option is deprecated and soon to be removed? You seem to be getting something wrong. When 1.7 gets released, gcc will not support the -mno-cygwin option anymore, but the distro will get a mingw cross-compiler nevertheless. You just have to use the cross-compiler i686-pc-mingw32 explicitely. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [Bug] Crash when using virtualedit=all
James Vega wrote: On Sat, Mar 07, 2009 at 04:30:30PM -0500, James Vega wrote: There seems to be an edge case when positioning the cursor and 'virtualedit' is set to all that causes gvim to crash. This was introduced between 6.4 and 7.0b. It can be reproduced using the attached files as follows: gvim -u NONE -N -S crash.vim crash.txt Actually attached this time. -- James Thanks. I can reproduce it with Vim-7.2.132 (huge) GTK2-GNOME. I see that windgoto() is called with with a negative col (-2147483646). Call stack when it happens is: #4 0x08190cd9 in windgoto (row=14, col=-2147483646) at screen.c:7888 #5 0x0819125e in setcursor () at screen.c:8118 #6 0x08107c16 in main_loop (cmdwin=0, noexmode=0) at main.c:1143 #7 0x081077e3 in main (argc=11, argv=0xbfd32a14) at main.c:939 I don't know why yet (I'll try to find out when I have time) but in the mean time, attached patch works around it. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: screen.c === RCS file: /cvsroot/vim/vim7/src/screen.c,v retrieving revision 1.114 diff -c -r1.114 screen.c *** screen.c 22 Feb 2009 20:13:34 - 1.114 --- screen.c 8 Mar 2009 09:43:30 - *** *** 7879,7884 --- 7879,7886 row = 0; if (row = screen_Rows) row = screen_Rows - 1; + if (col 0) /* why would this happen? */ + col = 0; if (col = screen_Columns) col = screen_Columns - 1;
Re: EOL for Cygwin - Win32 cross compiles
On Mar 7 21:15, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 9:05 PM, Tony Mechelynck wrote: The only interest of Make_cyg.mak is to compile Vim binaries which don't need Cygwin to run No, it allows for compiling either mingw OR cygwin binaries (at the moment). And, if you've ever tried to run a ./configure script on cygwin, you'll understand why that's still useful... Huh? Hello? If you have trouble using vim's configure and Makefile on Cygwin, then that's a case of PEBKAC. The vim package in the Cygwin distro is build that way all the time for ages. Please don't spread misinformation about Cygwin. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Mar 8 03:32, Tony Mechelynck wrote: On 08/03/09 03:15, Matt Wozniski wrote: This option will be removed when Cygwin migrates to Cygwin 1.7 / gcc 4. See http://www.cygwin.com/ml/cygwin/2008-09/msg00291.html . Removing the option has been planned for some time - it has never really worked correctly, it provides no significant advantages over simply using mingw to compile, and it has historically been very confusing to users. ~Matt If removing the option has always been confusing to users, then why can't they leave it in? The _option_ to compile native-Windows programs using Cygwin gcc _is_ a useful thing, I can't imagine on what grounds someone would think the opposite. Nobody thinks the opposite. Here's the deal: - On Linux, you build Linux binaries using the native gcc - On Solaris, you build Solaris binaries using the native gcc - On Linux, you build Solaris binaries using a cross-compiler called i386-pc-solaris2.11 - On Cygwin you build Cygwin binaries using the native gcc - On Mingw you build Mingw binaries using the native gcc - On Cygwin you build Mingw binaries using a cross-compiler called i686-pc-mingw32 The -mno-cygwin option was always just a hack. You could have put this hack into the Linux i686 compiler as well, but why would you? Same for Cygwin. The -mno-cygwin option will be removed. To build a Mingw binary, which is logically a cross-build, you will need a cross-compiler. With the move to the new Cygwin 1.7 release and the move to the latest gcc-4.x release, the -mno-cygwin option will be replaced by a mingw cross-compiler which will become part of the distro. Does that make sense? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: c/c++ comment highlighting bug with syntax on
cadabras wrote: I was at work last week and I was programming. I found a bug in c/c++ comment highlighting with syntax on. I replaced all [[:alnum:]] characters with A character. In this way I can submit it to this group. If I'm understanding you correctly, your workplace will permit you to submit some of your source code here as long as you have properly sanitized it to remove confidential information. For example, the phrase My Company Name would become AA AAA . How can I submit my c/c++ like file to show the bug? In short, just submit your sample of mis-behaving C/C++ as an email to the list. In case you were asking for more detail on the process, I'd recommend the following. It's best to reduce the size of your source code to the smallest possible example that demonstrates the bug. That makes it much easier on the volunteers on the list (and correspondingly more likely that you'll get help with your problem). Since you've indicated it's a problem with comment highlighting, you might be able to post a single C/C++ comment that shows the problem. Then, after shrinking the example as much as possible, email your example to the list (simply paste the example code directly into the email). Please include a good description of what you think is wrong. For example, instead of saying this doesn't highlight properly, you might say the third word comes out blue, but it should be yellow. You may have already seen this, but I've found the following document interesting and helpful for posting questions on mailing lists: http://www.catb.org/~esr/faqs/smart-questions.html Hope this helps, Michael Henry --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Mapping Bug (script, incomplete mapping, mbyte key code)
Andy Wokula wrote: A script mapping that produces a type ahead that Vim awaits completion for cannot be completed with a multi-byte key code. Script below: Notes: - This is quite a rare case, but bugging me for a long time ... at least I think it deserves mentioning. - For testing, the mappings will append Vim comments to the current buffer. - Either uncomment OK Mapping (mappings work as intended) or BUG Mapping (mappings reveal a bug in Vim) OK Mapping: nmap ff SIDfoo_ BUG Mapping: nmap script ff SIDfoo_ or :nnoremap script ff press ffg always ok nnoremap SIDfoo_g GoC-U ok: ffgEsc press ffC-G(single byte key code?) always ok nnoremap SIDfoo_C-G GoC-U ok: ffltC-GEsc press ffF8 (multi byte key code?) never executed with BUG Mapping: nnoremap SIDfoo_F8 GoC-U ok: ffltF8Esc instead, BUG Mapping executes the two mappings below: press ff$ always ok map that causes the timeout: nnoremap SIDfoo_ GoC-U quit: ffEsc press F8 always ok nnoremap F8 GoC-U ltF8Esc This is a bit confusing. Please give a reproducible example. I suppose you have both ff and ffg mapped, so that after typing ff Vim waits for the next character to find out what mapping applies. The Vim script you give suggests there also is a problem without script, so are there two problems? -- hundred-and-one symptoms of being an internet addict: 175. You send yourself e-mail before you go to bed to remind you what to do when you wake up. /// 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. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Mapping Bug (script, incomplete mapping, mbyte key code)
Bram Moolenaar schrieb: Andy Wokula wrote: A script mapping that produces a type ahead that Vim awaits completion for cannot be completed with a multi-byte key code. Script below: Notes: - This is quite a rare case, but bugging me for a long time ... at least I think it deserves mentioning. - For testing, the mappings will append Vim comments to the current buffer. - Either uncomment OK Mapping (mappings work as intended) or BUG Mapping (mappings reveal a bug in Vim) OK Mapping: nmap ff SIDfoo_ BUG Mapping: nmap script ff SIDfoo_ or :nnoremap script ff press ffg always ok nnoremap SIDfoo_g GoC-U ok: ffgEsc press ffC-G(single byte key code?) always ok nnoremap SIDfoo_C-G GoC-U ok: ffltC-GEsc press ffF8 (multi byte key code?) never executed with BUG Mapping: nnoremap SIDfoo_F8 GoC-U ok: ffltF8Esc instead, BUG Mapping executes the two mappings below: press ff$ always ok map that causes the timeout: nnoremap SIDfoo_ GoC-U quit: ffEsc press F8 always ok nnoremap F8 GoC-U ltF8Esc This is a bit confusing. Please give a reproducible example. I suppose you have both ff and ffg mapped, so that after typing ff Vim waits for the next character to find out what mapping applies. Right, and it is important that Vim waits for SIDfoo_ to be completed. At any time, 6 mappings are involved (see below). I'll try again: Script 1 (buggy): -- nmap script ff SIDfoo_ nnoremap SIDfoo_g GoC-U ok: ffgEsc nnoremap SIDfoo_C-G GoC-U ok: ffltC-GEsc nnoremap SIDfoo_F8 GoC-U ok: ffltF8Esc nnoremap SIDfoo_ GoC-U quit: ffEsc nnoremap F8 GoC-U ltF8Esc -- keys to type: ffF8 bad result in the buffer: quit: ff F8 Script 2 (ok): -- nmap ff SIDfoo_ nnoremap SIDfoo_g GoC-U ok: ffgEsc nnoremap SIDfoo_C-G GoC-U ok: ffltC-GEsc nnoremap SIDfoo_F8 GoC-U ok: ffltF8Esc nnoremap SIDfoo_ GoC-U quit: ffEsc nnoremap F8 GoC-U ltF8Esc -- keys to type: ffF8 good result in the buffer: ok: ffF8 If you type ffg or ffC-G the results are good with both scripts: ok: ffg ok: ffC-G If you type ff (and wait) or ff$ (where $ is not mapped), you'll get in all cases (good result): quit: ff The Vim script you give suggests there also is a problem without script, so are there two problems? Hmm, actually ... no. script is one of the conditions to show the problem. BTW: The following works ok (of course): -- nmap script ffF8 SIDfoo_F8 nnoremap SIDfoo_F8 GoC-U ok: ffltF8Esc -- Here Vim waits for ff to be completed, not for SIDfoo_ . -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] support for the bang in :diffthis (was Re: [PATCH] :diffoff should not change settings for non-diff windows)
Markus Heidelberg wrote: Bram Moolenaar, 06.03.2009: Markus Heidelberg wrote: Lech Lorens, 05.03.2009: Perfectly fine with me - I hardly ever use :diffoff without !, anyway. Is there a reason to not support the corresponding :diffthis! command? For consistency it seems like a good idea, instead of using two different ways :windo diffthis and :diffoff!. Furthermore :windo can move the cursor into another window, which is normally not desired. --- 8 --- Add support for :diffthis! for setting the diffmode in all windows in the current tab page. Makes sense. But it should skip special windows: help, quickfix, preview, etc. Sure, will do. What do you think, should the :diffthis! command set a special window into diffmode, if it is the current window or should it never adjust special windows? I guess the former solution would be more consistent, since :diffthis sets the current window into diffmode regardless of it being a special window or not. Yes, if you do :diffthis or :diffthis! then the current window should always go to diff mode. But :diffthis! should only include other windows that are normal to avoid trouble. It's perhaps a bit strange to use :diffthis! to start diff mode in other windows. :diffall would be more obvious. It's not symmetric with :diffoff vs :diffoff!, but that one doesn't say this. What do you all think about using :diffall instead? -- The CIA drives around in cars with the Intel inside logo. /// 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. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [Bug] Crash when using virtualedit=all
Dominique Pelle wrote: James Vega wrote: On Sat, Mar 07, 2009 at 04:30:30PM -0500, James Vega wrote: There seems to be an edge case when positioning the cursor and 'virtualedit' is set to all that causes gvim to crash. =A0This was introduced between 6.4 and 7.0b. It can be reproduced using the attached files as follows: =A0 gvim -u NONE -N -S crash.vim crash.txt Actually attached this time. -- James My previous patch was only a workaround, but this new attached patch should be the actual bug fix. Please review it. oldcol can be MAXCOL when entering function check_cursor_col(). Function check_cursor_col() compares oldcol to MAXCOL _after_ having added curwin-w_cursor.coladd to it, so as a result it fails to see that it was MAXCOL. Attached patch fixes it. Thanks for the patch! -- If Microsoft would build a car... ... Occasionally your car would die on the freeway for no reason. You would have to pull over to the side of the road, close all of the car windows, shut it off, restart it, and reopen the windows before you could continue. For some reason you would simply accept this. /// 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. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: c/c++ comment highlighting bug with syntax on
If I'm understanding you correctly, your workplace will permit you to submit some of your source code here as long as you have properly sanitized it to remove confidential information. For example, the phrase My Company Name would become AA AAA . Yes, you are, but I did not replace only strings like My Company Name, but also strings like class MyClass : public MyMotherClass with A AAA : AA A It's best to reduce the size of your source code to the smallest possible example that demonstrates the bug. My file is large and I cannot reduce it very much because the problem occurs only with files with big c/c++ comments. My file is a typical bad designed c++ class: a lot of bad code and a lot of useless commented old code. I obviously can submit a good description to reproduce the problem. I could submit the file using rapidshare.de. Do you agree? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] support for the bang in :diffthis (was Re: [PATCH] :diffoff should not change settings for non-diff windows)
Bram Moolenaar, 08.03.2009: Markus Heidelberg wrote: Bram Moolenaar, 06.03.2009: Markus Heidelberg wrote: Lech Lorens, 05.03.2009: Perfectly fine with me - I hardly ever use :diffoff without !, anyway. Is there a reason to not support the corresponding :diffthis! command? For consistency it seems like a good idea, instead of using two different ways :windo diffthis and :diffoff!. Furthermore :windo can move the cursor into another window, which is normally not desired. --- 8 --- Add support for :diffthis! for setting the diffmode in all windows in the current tab page. Makes sense. But it should skip special windows: help, quickfix, preview, etc. Sure, will do. What do you think, should the :diffthis! command set a special window into diffmode, if it is the current window or should it never adjust special windows? I guess the former solution would be more consistent, since :diffthis sets the current window into diffmode regardless of it being a special window or not. Yes, if you do :diffthis or :diffthis! then the current window should always go to diff mode. But :diffthis! should only include other windows that are normal to avoid trouble. It's perhaps a bit strange to use :diffthis! to start diff mode in other windows. That's for sure! :diffall would be more obvious. It's not symmetric with :diffoff vs :diffoff!, but that one doesn't say this. What do you all think about using :diffall instead? Or what about :diffon[!] ? :diffon would be a synonym for :diffthis then and there would be symmetry with :diffoff[!] in terms of invocation and spelling. Maybe this could be declared as the preferred method then. Indeed I already wondered, why it was called :diffthis instead of :diffon, since there was a :diffoff. And then I read that :diffoff was introduced a major version later than :diffthis. I guess if they were introduced at the same time, it wouldn't have been called :diffthis. Markus --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [PATCH] support for the bang in :diffthis (was Re: [PATCH] :diffoff should not change settings for non-diff windows)
Markus Heidelberg schrieb: Bram Moolenaar, 08.03.2009: Markus Heidelberg wrote: Bram Moolenaar, 06.03.2009: Markus Heidelberg wrote: Lech Lorens, 05.03.2009: Perfectly fine with me - I hardly ever use :diffoff without !, anyway. Is there a reason to not support the corresponding :diffthis! command? For consistency it seems like a good idea, instead of using two different ways :windo diffthis and :diffoff!. Furthermore :windo can move the cursor into another window, which is normally not desired. --- 8 --- Add support for :diffthis! for setting the diffmode in all windows in the current tab page. Makes sense. But it should skip special windows: help, quickfix, preview, etc. Sure, will do. What do you think, should the :diffthis! command set a special window into diffmode, if it is the current window or should it never adjust special windows? I guess the former solution would be more consistent, since :diffthis sets the current window into diffmode regardless of it being a special window or not. Yes, if you do :diffthis or :diffthis! then the current window should always go to diff mode. But :diffthis! should only include other windows that are normal to avoid trouble. It's perhaps a bit strange to use :diffthis! to start diff mode in other windows. That's for sure! :diffall would be more obvious. It's not symmetric with :diffoff vs :diffoff!, but that one doesn't say this. What do you all think about using :diffall instead? Or what about :diffon[!] ? :diffon would be a synonym for :diffthis then and there would be symmetry with :diffoff[!] in terms of invocation and spelling. Maybe this could be declared as the preferred method then. Indeed I already wondered, why it was called :diffthis instead of :diffon, since there was a :diffoff. And then I read that :diffoff was introduced a major version later than :diffthis. I guess if they were introduced at the same time, it wouldn't have been called :diffthis. Markus I'd prefer :diffall over :diffon!: When there are three commands for diffing, it will be clearer what :diffall means. Later :diffall! can be added to really include all windows in the diff. :diffon! and :diffoff! wouldn't be exact opposites: if other windows are special, :diffoff! may include them, unlike :diffon!. -- Andy --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Mar 8 10:53, Corinna Vinschen wrote: On Mar 8 03:32, Tony Mechelynck wrote: If removing the option has always been confusing to users, then why can't they leave it in? The _option_ to compile native-Windows programs using Cygwin gcc _is_ a useful thing, I can't imagine on what grounds someone would think the opposite. Nobody thinks the opposite. Here's the deal: - On Linux, you build Linux binaries using the native gcc - On Solaris, you build Solaris binaries using the native gcc - On Linux, you build Solaris binaries using a cross-compiler called i386-pc-solaris2.11 i386-pc-solaris2.11-gcc - On Cygwin you build Cygwin binaries using the native gcc - On Mingw you build Mingw binaries using the native gcc - On Cygwin you build Mingw binaries using a cross-compiler called i686-pc-mingw32 i686-pc-mingw32-gcc I assume that was clear but sorry about the typos anyway. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: EOL for Cygwin - Win32 cross compiles
On Sun, Mar 8, 2009 at 5:40 AM, Corinna Vinschen wrote: On Mar 7 20:35, Matt Wozniski wrote: On Sat, Mar 7, 2009 at 12:35 PM, Tony Mechelynck wrote: That's if you want Vim for Cygwin. You can also use Cygwin to compile (cross-compile, if you want) versions of Vim which don't need Cygwin to run, as explained on my Windows HowTo Hm. Support for using cygwin's gcc to do cross-compile builds is soon to be dropped. Maybe we should remove the option to do this from Make_cyg.mak? Or, at least add a note to the README noting that the option is deprecated and soon to be removed? You seem to be getting something wrong. When 1.7 gets released, gcc will not support the -mno-cygwin option anymore, but the distro will get a mingw cross-compiler nevertheless. You just have to use the cross-compiler i686-pc-mingw32 explicitely. No, I understood that, and was just failing to make myself clear in the email. The reason I brought this up was to suggest that either Make_cyg.mak be removed entirely, or that it be changed to use a cross-compiler explicitly rather than use the -mno-cygwin switch. If this were to be changed, we'd want to do it now, rather than after Cygwin 1.7's official release. In retrospect, I wasn't terribly clear at all, so sorry for the confusion. ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: c/c++ comment highlighting bug with syntax on
cadabras wrote: If I'm understanding you correctly, your workplace will permit you to submit some of your source code here as long as you have properly sanitized it to remove confidential information. For example, the phrase My Company Name would become AA AAA . Yes, you are, but I did not replace only strings like My Company Name, but also strings like class MyClass : public MyMotherClass with A AAA : AA A Understood. My file is large and I cannot reduce it very much because the problem occurs only with files with big c/c++ comments. Some problems are like that :-( I obviously can submit a good description to reproduce the problem. I could submit the file using rapidshare.de. Do you agree? That sounds like a reasonable thing to me. I'm unfortunately not expert in the area of syntax highlighting, so I expect to remain silent when your question shows up. But there are a number of helpful experts on this mailing list, so if you make your code available in a relatively easy to access manner (no login required, etc.) and someone recognizes what's going on, they will probably try to help you. Hope this helps, Michael Henry --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
RE: [PATCH] support for the bang in :diffthis (was Re: [PATCH] :diffoff should not change settings for non-diff windows)
Bram Moolenaar wrote: It's perhaps a bit strange to use :diffthis! to start diff mode in other windows. :diffall would be more obvious. It's not symmetric with :diffoff vs :diffoff!, but that one doesn't say this. What do you all think about using :diffall instead? There is already quite a bit of history in Vim, so I would prefer to NOT introduce a new command. The following looks logical to me: Go to window 1 :diffthis Go to window 2 :diffthis Remove diff from all visible windows :diffoff! Apply diff to all visible (normal) windows :diffthis! John --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
