Re: confirm unsubscribe from vim@vim.org
RE: OT: Vi in a browser...
-Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: 1. juni 2007 07:32 To: vim@vim.org Subject: Re: OT: Vi in a browser... On 31/05/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Edward L. Fox wrote: [...] A friend told me that he is developing a Firefox addon to emulate the Vi/Vim behaviors in all text areas in Firefox, without launching external applications. I'm looking forward to it. [...] I don't think any Vim extension aiming at reproducing Vim's behaviour without actually calling it, will be able to come near the result of the gazillions of man-hours Bram (with a few others) has put and is still putting into it. Many browsers are able to interact with any external editor (such as true-blue Vim) these days, which also means that any bugfix or improvement to Vim gets reflected in the editing behaviour of the browser. Or you could always write the text in Vim, then use the clipboard to paste it into the browser, even with no special external editor function. Agreed. Maybe Edward should persuade his friend to use the OLE interface of Vim instead. Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ Personally, I don't agree with you. When editing short text items on web pages, I feel that the overhead of copying/pasting back and forth from vim is too much. I am currently using the View Source With-addon, which is great, but I would actually prefer a limited vi-implementation for use inside Firefox. So, Edward, please post to this list if/when your friend has something that we may try out :-) Thomas Svensen Senior Solutions Engineer FAST
Re: OT: Vi in a browser...
Hi Thomas, On 01/06/07, Thomas Svensen [EMAIL PROTECTED] wrote: -Original Message- From: Yongwei Wu [mailto:[EMAIL PROTECTED] Sent: 1. juni 2007 07:32 To: vim@vim.org Subject: Re: OT: Vi in a browser... On 31/05/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Edward L. Fox wrote: [...] A friend told me that he is developing a Firefox addon to emulate the Vi/Vim behaviors in all text areas in Firefox, without launching external applications. I'm looking forward to it. [...] I don't think any Vim extension aiming at reproducing Vim's behaviour without actually calling it, will be able to come near the result of the gazillions of man-hours Bram (with a few others) has put and is still putting into it. Many browsers are able to interact with any external editor (such as true-blue Vim) these days, which also means that any bugfix or improvement to Vim gets reflected in the editing behaviour of the browser. Or you could always write the text in Vim, then use the clipboard to paste it into the browser, even with no special external editor function. Agreed. Maybe Edward should persuade his friend to use the OLE interface of Vim instead. Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ Personally, I don't agree with you. When editing short text items on web pages, I feel that the overhead of copying/pasting back and forth from vim is too much. I am currently using the View Source With-addon, which is great, but I would actually prefer a limited vi-implementation for use inside Firefox. I must have been unclear. I meant to agree with the part `I don't think any Vim extension aiming at reproducing Vim's behaviour without actually calling it, will be able to come near the result of the gazillions of man-hours Bram (with a few others) has put and is still putting into it'. So I suggested some embedded Vim inside Firefox using an add-on. So, Edward, please post to this list if/when your friend has something that we may try out :-) Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Re: how can I add this feature to vim!!
Hi jaywee,
The simplest way is using a mapping
inoremap { {cr}escO
which should do what you want.
But I myself find this terrible annying because it always inserts those
closing braces.
That's why I've written some kind of context sensitive completion
http://www.mawercer.de/marcweber/vim/installer/vimlib_contextcompletion_installer_sourceme.vim
After sourceing you can save to different folder and use set
runtime+=differentfolder.
Then you can use
call vl#lib#completion#contextcompletion#InitContextCompletion(
\ [ [ Tab,'tab','b:tab_compl']
\ , [ MCR ,m-cr ,'b:mcr_compl', \cr ]
\ , [ CR ,cr ,'b:cr_compl', \cr ]
\ , [ BO ,{ ,'b:bo_compl', { ]
\ ]
\ )
this will generate severeal commands
You are interested in
(BO = brace open ;)
AddBOCompletion bcm: {\cr}\escO
If you only want this behaviour after functions and whiles I'd suggest
AddBOCompletion bcm:)$ {\cr}\escO
which means do this only if the regex )$ matches before the cursor
Here are some further examples which map
d
id
to
#ifdef
#include |
#include |
function! vl#dev#cpp#context_completions#AddCPPCompletions()
AddTabCompletion ^d \bs#define ts:
AddTabCompletion ^id \bs\bs#ifdef\cr#endif\esc-A ts:
AddTabCompletion ^ \bs#include\space\left
AddTabCompletion ^\ \bs#include\space\\\left
endfunction
If more than one context matches you'll get a list or can resolve it by adding
AddTabCompletion a a\spacetab\spacepressed
AddTabCompletion a a\spacetab\spacepressed2 fitness:2
which means use the second because its fitness is greater.
I've mapped opening cloning brace to m-cr (AddMCRCompletion) to be able to
decide wether I want this behaviour..
My scipts are overkill for this task but they might become handy if you
really many mappings because you can map more than one string/action to
the same key.
Marc
Re: can't diffsplit
I'm having the same problem, and the three solutions don't work for me. In all the three solutions (and even the other thread I started with your reply windo diffthis) doesn't work. What happens is that one window folds the complete file to one line. The other window keeps the file open as it was. Is this normal vim diffthis behaviour? I was expecting somekind of Winmerge behaviour. Rgds, Eric I. To diff one file already being edited with another file not being edited: 1. make the file already being edited current (let's say foo.txt) 2. :vertical diffsplit bar.txt II. To diff two files already being edited: 1. make one file current 2. :diffthis 3. make the other file current 4. :diffthis 5. (Optional) Rearrange the windows (using ^W commands) to place them side-by-side. III. To diff (in an existing Vim, but in new windows) two files not being edited 1. :bot new foo.txt 2. :vert diffsplit bar.txt
Re: how can I add this feature to vim!!
On Fri, Jun 01, 2007 at 01:05:53PM +0800, jaywee wrote:
mostly when I press {, I have to press one more } after, because
they are always appears at the same time! the same as () [], and
also the quote mark(). so I wonder how can I add the feature that when
I insert { or the other punctuations above, it will automatically add
} !!!
http://marc.info/?l=vimm=117912217106498w=2
besides, I wonder how can I make vim to break the line automatically??
set fo+=t
you may want other flags beside t (r, o, a, w...), see
:h 'fo
:h fo-table
and I find a great tip named #166 which tells me how to switch Capslock
to esc, the tip goes to like this:
add
*! Swap caps lock and escape, good for Vim
remove Lock = Caps_Lock
keysym Escape = Caps_Lock
keysym Caps_Lock = Escape
add Lock = Caps_Lock
*to a file named .speedswapper to the home directory, and run *xmodmap
~/.speedswapper* in a terminal, I follow the guide and finally done! but
the bad thing is I have to run the command every time I reboot ubuntu!!
Add it to ~/.xinitrc before the line executing the window
manager. Hm, Ubuntu is a desktop distro, so this probably
won't work... Therefore use the desktop thing that lets you
set up programs to be run when the desktop is initialized
and add the command there. Where to find this thing strongly
depends on the desktop environment.
maybe too much questions!
And so much punctuation...
Yeti
--
http://gwyddion.net/
Syntax highlighting, TOhtml and diff
I am looking for a small extension to :TOhtml and I wonder if it can be done already, extists as a plug-in or if this is an itch I will have to scratch. This is what I want: I have a file, let's say myapp.c, which should be converted to (X)HTML with syntax highlighting intact. So far so good, it can be done already, *but* I would like to first run a diff against another file (maybe myapp.c.old) and get lines that have been added or modified to have a slightly different background color (light grey, if I use a white background for instance). It would be an added bonus if I could run a diff against some command output (hg diff, in my case). I've searched a bit both on vim.org and via Google but so far not been able to find anything (quite possibly due to the fact that I'm using suboptimal search terms). I don't think I'm the only person in the world who wants to be able to do this, and I'm hoping somebody on the list can point me in the right direction.
Calling silent expand abbrev
Hi, all. In insert mode command C-] expand abbreviation. How to call this command in function? I try this way: execute normal i\C-] but it simply put ^] in text. -- Serhiy Boiko CRIS-UANIC
RE: OT: Vi in a browser...
Personally, I don't agree with you. When editing short text items on web pages, I feel that the overhead of copying/pasting back and forth from vim is too much. I am currently using the Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? I have to essentially do 1GVGctl-del to stick everything into the scratchpad/clipboard/whatever to dump it back into the item from whence it originally came, and that's just a pain. Well, not so much a pain as an annoying itch I can't quite reach. I was thinking something along the lines of %V but that obviously won't work. :)
Re: OT: Vi in a browser...
Gene Kwiecinski wrote: Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? To copy the entire file to the system clipboard, you can do: :%y+ Rpelace y with d if you want to cut instead of copy. Replace + with * if you want to use middle-click to paste (on X11.) Tobia
Re: OT: Vi in a browser...
Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? I have to essentially do 1GVGctl-del to stick everything into the scratchpad/clipboard/whatever to dump it back into the item from whence it originally came, and that's just a pain. Well, not so much a pain as an annoying itch I can't quite reach. I was thinking something along the lines of %V but that obviously won't work. :) You're so close, it could bite you :) It looks like you're getting hung up on expecting the solution to need visual mode rather than just using Ex commands. I frequently use :%d or if I need it to go to the system clipboard, :%d* :%d+ I use these (and their yanking counterparts, :%y) so regularly that they're ingrained muscle-memory. Because the y/d Ex command takes any range, I also regularly use :.,$d to do just from my current line to the EOF, or :1,.d to pull from the first line through the current line. -tim
gvim 7 highlight search string
In the old gvim, doing a search (/something) highlights all something in red. In gvim 7, it doesn't highlight all occurrences. Is there a way to turn this back on? Thanks!
Re: gvim 7 highlight search string
In the old gvim, doing a search (/something) highlights all something in red. In gvim 7, it doesn't highlight all occurrences. Is there a way to turn this back on? It sounds like in the process, a vimrc (system-wide?) was changed. You don't mention your distro/OS, so it's hard to help there. However, in your $HOME/.vimrc (or _vimrc on Win32), you can simply add the line set hls to turn on highlighting your searches by default. If you just want to turn it on for a current session, you can use it as an Ex command: :set hls or toggle it with :set hls! Using this method, it's not preserved across runs of Vim though (which is what the vimrc is for). -tim
Re: OT: Vi in a browser...
Gene Kwiecinski wrote: Personally, I don't agree with you. When editing short text items on web pages, I feel that the overhead of copying/pasting back and forth from vim is too much. I am currently using the Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? I have to essentially do 1GVGctl-del to stick everything into the scratchpad/clipboard/whatever to dump it back into the item from whence it originally came, and that's just a pain. Well, not so much a pain as an annoying itch I can't quite reach. I was thinking something along the lines of %V but that obviously won't work. :) It may depend on what you want to do with the selection: see the commands :yank, :put, delete, all of which accept a range and a register: To copy the whole file to the clipboard: :%y+ To cut (delete) the whole file to the clipboard (not very useful for the whole file, but it may be interesting for a different range): :%d+ To paste the clipboard after the last line: :$put+ To paste the clipboard before the first line: :0put+ To paste the clipboard linewise after the current line: :put+ Without the + at the end, all these act on the default (unnamed) register. Best regards, Tony. -- Bravely bold Sir Robin, rode forth from Camelot, He was not afraid to die, Oh Brave Sir Robin, He was not at all afraid to be killed in nasty ways Brave, brave, brave, brave Sir Robin. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
collapsing single lines of html tag attributes via plugin??
Hi all, first post. Been a long long time vi user but bizarrely never made the jump to vim until quite recently. I'm editing a lot of complex html/cake-php thtml templates at the moment and despite useful color highlighting I'm finding it quite difficult to see the wood for the trees due to the complex templates i have to edit. Typically for example, I've got tags with just about every possible attribute populated stretching over 3-4 lines sometimes. Imagine that embedded in huge multi level tables with specific tags I'm stuck with the templates to adhere to corporate style. I wondered whether there was a plugin somewhere that was able to abbreviate or partially hide the detail so i can see the overall structure more clearly. In essence I would like to collapse huge (single) lines of tags to something like a id=xyz href=/img ... - where implies I could expand if required. I'm sure it is probably possible to craft a plugin to do this, i just have some urgent deadlines right now ;) For lots of boring reasons I don't have the option of funky graphical html editors or environments - i'm in a remote shell using vim in text mode. Apologies if this is in the plugins, i wasn't quite sure what terms to search for. Hope what I wrote makes sense and someone recognises it! Howard -- -- Howard Glynn [ [EMAIL PROTECTED] ] Edinburgh, UK
Re: collapsing single lines of html tag attributes via plugin??
Been a long long time vi user but bizarrely never made the jump to vim until quite recently. Welcome! I'm editing a lot of complex html/cake-php thtml templates at the moment and despite useful color highlighting I'm finding it quite difficult to see the wood for the trees due to the complex templates i have to edit. Typically for example, I've got tags with just about every possible attribute populated stretching over 3-4 lines sometimes. Imagine that embedded in huge multi level tables with specific tags I'm stuck with the templates to adhere to corporate style. Well, since they can be slightly reformatted, as HTML generally ignores whitespace, you may be able to use an external tool like tidy to clean up the code so it's a bit easier to read. It should also help with normalizing the indentation. You may also be interested in reading about folding which collapses multiple lines into one: :help folding You can manually create folds to hide away particularly nettlesome segments if there are just a handful, or you can go for a more automated way of folding them. Folds are only line-wise rather than character-wise (though there is an vim patch floating around to also do column-wise folding...this is hearsay, as I've never tried it). Folding can be done by a variety of methods, defaulting to manual, but also allowing it to be done by syntax, by expression, or by indentation. Or even the manual folding can be done in a semi-automated fashion via a :g command such as :g/[^]*$/.,//fold which may be a good first place to start. If you used tidy and it has normalized indentation, you can just use :set foldmethod=indent and it may allow you to get a bird's-eye view of your code. to abbreviate or partially hide the detail so i can see the overall structure more clearly. In essence I would like to collapse huge (single) lines of tags to something like a id=xyz href=/img ... - where implies I could expand if required. Another lazy option might just be to visually hide it with something like :match Ignore /\_[^]*/ which will just hide all the tags (making them background-color on background-color). This is dangerous if you start editing and treat them like you would treat whitespace, but it can help make your content pop. Or you might try /\s*\w\+\s\+\zs\_[^]*/ which will just discolor your attribtes. If you want to see them but make them more subdued, you can opt for a different highlighting group than Ignore, something like :match Comment /.../ where, at least in my setup, Comment is dark grey on black which allows me to see it, but it isn't quite as intrusive. When done, you can un-:match them with :match none You can read all about this at :help :match For lots of boring reasons I don't have the option of funky graphical html editors or environments - i'm in a remote shell using vim in text mode. You have Vim...what more do you need? ;-) Hope this gives you some ideas with which to work... -tim
Re: :scriptfiles
On 2007-06-01, Tushar Desai [EMAIL PROTECTED] wrote: I was previously able to do :scriptfile for vim 7.1 (on Fedora Core 6), when I was debugging why my plugins won't work. Then to check if plugins would work in vim 7.0, I did a make install from vim 7.0. Since they didn't seem to work in vim 7.0, I reverted back to vim 7.1, by doing a make install from vim 7.1 directory. Now, if I type :scriptfile, vim complains that it is not an editor command. (I'm seeing the same issue on Ubuntu Feisty with vim 7.1.) Any ideas why it would stop working? (Probably that will also explain why my plugins are not working.) I don't think there has ever been a :scriptfile command, but there is a :scriptnames command. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: gvim 7 highlight search string
On 6/1/07, Tim Chase [EMAIL PROTECTED] wrote: In the old gvim, doing a search (/something) highlights all something in red. In gvim 7, it doesn't highlight all occurrences. Is there a way to turn this back on? It sounds like in the process, a vimrc (system-wide?) was changed. You don't mention your distro/OS, so it's hard to help there. However, in your $HOME/.vimrc (or _vimrc on Win32), you can simply add the line set hls to turn on highlighting your searches by default. If you just want to turn it on for a current session, you can use it as an Ex command: :set hls or toggle it with :set hls! Using this method, it's not preserved across runs of Vim though (which is what the vimrc is for). -tim If Brian is running Ubuntu that could have happened. When I mentioned on the list how updating changes default (to Ubuntu) behavior this was another symptom (I think.) -- -fREW
Re: :scriptfiles
Tushar Desai wrote: I was previously able to do :scriptfile for vim 7.1 (on Fedora Core 6), when I was debugging why my plugins won't work. Then to check if plugins would work in vim 7.0, I did a make install from vim 7.0. Since they didn't seem to work in vim 7.0, I reverted back to vim 7.1, by doing a make install from vim 7.1 directory. Now, if I type :scriptfile, vim complains that it is not an editor command. (I'm seeing the same issue on Ubuntu Feisty with vim 7.1.) Any ideas why it would stop working? (Probably that will also explain why my plugins are not working.) thanks, -tushar. :scriptfile is indeed not an editor command. You may have misremembered the name of the scriptnames command. :scrCtrl-D or, with 'wildmode' on, :scrTab would have shown you :scriptnames and :scriptencoding. Best regards, Tony. -- Error:015 - Unable to exit Windows. Try the door.
Re: OT: Vi in a browser...
On 6/1/07, Tim Chase [EMAIL PROTECTED] wrote: Speaking of which, is there any quicker way to visually select the entire file, analogous to ^A in other systems? I have to essentially do 1GVGctl-del to stick everything into the scratchpad/clipboard/whatever to dump it back into the item from whence it originally came, and that's just a pain. Well, not so much a pain as an annoying itch I can't quite reach. I was thinking something along the lines of %V but that obviously won't work. :) You're so close, it could bite you :) It looks like you're getting hung up on expecting the solution to need visual mode rather than just using Ex commands. I frequently use :%d or if I need it to go to the system clipboard, :%d* :%d+ I use these (and their yanking counterparts, :%y) so regularly that they're ingrained muscle-memory. Because the y/d Ex command takes any range, I also regularly use :.,$d to do just from my current line to the EOF, or :1,.d to pull from the first line through the current line. -tim Awesome. Tim is our ex friend. Or something? -- -fREW
Re: OT: Vi in a browser...
On 5/30/07, Tim Chase [EMAIL PROTECTED] wrote: Just stumbled across this link: http://gpl.internetconnection.net/vi/ for a basic implementation of Vi, authored in JavaScript. Sick, sick, sick. So just in case you're on a foreign computer that doesn't have vi/vim installed, and you need a fix, you can get it via the web. :) But you can't read/save disk files out of javascript, can you ? I thought javascript can't. Yakov
Re: collapsing single lines of html tag attributes via plugin??
Howard Glynn wrote: In essence I would like to collapse huge (single) lines of tags to something like a id=xyz href=/img ... There is a simple solution, maybe too simple, but... if you only have one tag per line, or if you can reformat your file in such a way, it might be enough to disable line wrap: :set nowrap You can map a function key to toggling line wrap: :map F9 :set wrap!CR Type that literally, with and everything, or put it into ~/.vimrc HTH Tobia
Re: collapsing single lines of html tag attributes via plugin??
Howard Glynn wrote: snip I wondered whether there was a plugin somewhere that was able to abbreviate or partially hide the detail so i can see the overall structure more clearly. In essence I would like to collapse huge (single) lines of tags to something like a id=xyz href=/img ... - where implies I could expand if required. I'm sure it is probably possible to craft a plugin to do this, i just have some urgent deadlines right now ;) snip Hello! Sounds like Vince Negri's conceal patch to vim would come in handy for this. Vim's current folding is on a line-by-line basis; Negri's patch can also perform concealing in lines. You can get his patch at: http://vince.negri.googlepages.com/ Here's an example, although it may conceal more than what you've requested... if has(conceal) if conc == 0 let conc= 3 endif syn clear syn region htmlTag conceal start= end= endif So this will conceal anything between ... . One neat thing; even though I've selected conceal level 3, nonetheless, when your cursor is atop a line that line will *not* be concealed. So editing may proceed, as that's what Vim's for. A more comprehensive (but not html-related) example of concealing is available at my website: see AnsiEsc.vim. This plugin will conceal ansi escape codes and perform proper colorizing of the text based on the concealed ansi codes. Vince N has a tex.vim syntax using concealment, too, somewhere... BTW, folks -- if more people than H Glynn would want this -- let Bram know! He's under the impression that its not wanted very much, which is why I presume its not in vim 7.x. Vince's patch also supports ownsyntax. Read about it at his website. Regards, Chip Campbell
Re: gvim 7 highlight search string
Brian E. Lozier wrote: In the old gvim, doing a search (/something) highlights all something in red. In gvim 7, it doesn't highlight all occurrences. Is there a way to turn this back on? I suspect that you may be having problems because you made changes to files in files in your former $VIMRUNTIME (use :echo $VIMRUNTIME when running vim to see where that is). Those files should not be changed, added to, etc, unless you don't mind having to re-do all such changes when next you upgrade vim. Instead: * put settings, most customizations, etc in $HOME/.vimrc (linux) $HOME\_vimrc (windows) You can find out where your $HOME is by typing :echo $HOME when you're running vim. * Put plugins into $HOME/.vim/plugin/ (linux) $HOME\vimfiles\plugin\ (windows) * Put autoload plugins into $HOME/.vim/autoload/ (linux) $HOME\vimfiles\autoload\ (windows) * Put colorschemes into $HOME/.vim/colors/ (linux) $HOME\vimfiles\colors\ (windows) The setting in question here is: hls You'll probably should include the following in your .vimrc (_vimrc), too: set nocp if version = 600 filetype plugin indent on endif Regards, Chip Campbell
Re: collapsing single lines of html tag attributes via plugin??
On 6/1/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Howard Glynn wrote: snip I wondered whether there was a plugin somewhere that was able to abbreviate or partially hide the detail so i can see the overall structure more clearly. In essence I would like to collapse huge (single) lines of tags to something like a id=xyz href=/img ... - where implies I could expand if required. I'm sure it is probably possible to craft a plugin to do this, i just have some urgent deadlines right now ;) snip Hello! Sounds like Vince Negri's conceal patch to vim would come in handy for this. Vim's current folding is on a line-by-line basis; Negri's patch can also perform concealing in lines. You can get his patch at: http://vince.negri.googlepages.com/ Here's an example, although it may conceal more than what you've requested... if has(conceal) if conc == 0 let conc= 3 endif syn clear syn region htmlTag conceal start= end= endif So this will conceal anything between ... . One neat thing; even though I've selected conceal level 3, nonetheless, when your cursor is atop a line that line will *not* be concealed. So editing may proceed, as that's what Vim's for. A more comprehensive (but not html-related) example of concealing is available at my website: see AnsiEsc.vim. This plugin will conceal ansi escape codes and perform proper colorizing of the text based on the concealed ansi codes. Vince N has a tex.vim syntax using concealment, too, somewhere... BTW, folks -- if more people than H Glynn would want this -- let Bram know! He's under the impression that its not wanted very much, which is why I presume its not in vim 7.x. Vince's patch also supports ownsyntax. Read about it at his website. Regards, Chip Campbell I would use conceal if it were in standard vim. Definitely. -- -fREW
Re: :scriptfiles
Tushar Desai wrote: sorry ... my bad. it is scriptnames and not scriptfiles. but, my plugins still won't work. :-( regards, -tushar. If nothing else avails, you may try executing Vim step-by-step, see :help debug-scripts. Best regards, Tony. -- The price of seeking to force our beliefs on others is that someday they might force their beliefs on us. -- Mario Cuomo
Re: can't diffsplit
Eric Leenman wrote: I'm having the same problem, and the three solutions don't work for me. In all the three solutions (and even the other thread I started with your reply windo diffthis) doesn't work. What happens is that one window folds the complete file to one line. The other window keeps the file open as it was. Let's start from scratch. Say you have two files, old.txt and new.txt, where they are similar but different. You run: gvim -d old.txt new.txt You should see the two files side-by-side. Groups of lines that are identical are folded. Differences are highlighted. Each vertical split has a fold column (grey by default) down the left side. Does the above work? When you follow Tony's advice, do you see the same fold column in each split? If not, you need to switch to the split missing the fold column and type ':diffthis'. I was expecting somekind of Winmerge behaviour. Winmerge can do some great stuff, but Vim differencing of two file is better because Vim folds lines that are the same. John
