Gary, Tony, et. al., thank you for your input, case closed by now. I have noted your comments and will streamline my linux environment.
I understand I could not find any mapping of ctrl-v on my machine because it is the default and does not need any mapping. I did not know that. Regarding my colleague's machine, the situation was more funny, I was fooled by fast typing that is vim's side effect. :) It turned out I was correct when commented out sourcing the mswin.vim script yesterday from his _vimrc, and in fact we were landing in visual block mode when hitting ctrl-v since the beginning. But it has turned on visual block mode for a second only, which I haven't noticed because I turned it off immediately on the first cursor key movement. My bad, I was not checking the status line for mode, which is another side effect of vim, i.e. I "feel" the mode. :) Now I understand it was because "behave mswin" just below the source mswin.vim line in his _vimrc. I had to comment that ot too and after that he got the desired behaviour. So case is closed. Sorry for this noise, now I recall how this all has happened to me: I was using gvim on Linux since ages, and in fact I was carrying my vimrc file from there, I was not fiddling with the factory default one, in fact it is the first time I have seen _vimrc with source mswin.vim and behave mswin. And this is the funniest (now, in retrospect): I was even wrong with my statement yesterday saying I am sourcing mswin.vim. This is not the case. There is a dangling instance of _vimrc that was put there by the windows install, but it turned out vim is hardly ever using it. It seems I actually have two windows home directories, and both the windows system variable and $HOME vim variable are consistently pointing to one of them, depending if I am booted up connected to the company network (=network home) or anywhere else outside (=local disk home). I did not even know that, I just realised that. I must have installed vim disconnected, because it has placed a factory default into c:\users\myhome, which I did not even know can be my home under some circumstances. I thought my home is under h:\, on a network mounted drive that is backed up. I was debugging the wrong, factory default _vimrc yesterday, not the on that was sourced. Some debugging with -D and :scripts revealed this today. Seems I have never been using gvim outside the networked home, either because for that I am using my Linux machine at home, or come back to the corporate network via a vpn from the vista laptop. The behaviour would have changed if I would fire up a gvim booted up outside network without vpn, I think. Lesson learnt, I did overwrite all instances of _vimrc with "mine", just in case. There is no dangling factory default _vimrc waiting to attack as a surprise anymore. Finally, a small discovery: I was playing with the numbers in -V to govern the verbosity level, but nowhere could find what the numbers actually mean and what is the allowed range. But seems -V20 has anything verbatim that has been sourced. Thank you for all your support, this list is wonderful. Have a nice day, Peter 2009/12/8 Tony Mechelynck <[email protected]> On 08/12/09 17:35, Peter Princz wrote: > >> Dear vimmers on this list, >> please help me with my problem, it is driving me crazy, I'm giving up. >> It is the flip question that we normally have, i.e. I cannot reproduce a >> behaviour on a fresh install that works as expected on my machine, I >> just can't remember how did I this. >> I am on gvim 7.2 in parallel on linux and windows. >> Have one vimrc file that is named as _vimrc on windows and .gvimrc on >> linux. >> > > this is dangerous: _vimrc is sourced on every startup, before the plugins; > .gvimrc is not sourced at all in Console Vim and only after the plugins in > gvim. Even on Unix, ~/_vimrc will be used if there is no ~/.vimrc so you > could soft-link it under its own name, let's say something like > > cd > ln -sv /mnt/dos/c/Documents\ and\ Settings/princzp/_vimrc > rm -vf .gvimrc > > Of course, modify the above depending on the Unix mount point for Windows > C: partition and for the exact name of your Windows $HOME directory. > > > I am using ctrl-ins, shift-ins for copy/paste on windows as well, >> ctrl-v is vsual block in both environments. >> Everything is fine, I could not be happier, and I haven't touch these >> _vimrc/.gvimrc files this year. >> Ironically, even mswin.vim is left as sourced i.e. not commented out, >> yet everything works. >> ...And then my colleague walked by and became envy on my ctrl-v and >> clipboard handling shortcuts. But I cannot reproduce my settings at his >> machine. >> My _vimrc is 10 kBytes, my colleague would want just the needed settings >> to be merged into his _vimrc. >> > > Ctrl-V and clipboard handling mappings are those set up by mswin.vim. They > are very "un-vimmish" and they hide useful Vim keystrokes, so I would advise > you (and your colleague) not to use them, but after all, it's your funerals. > > > > I've been playing around half on hour by toggling on/off the settings >> one by one I have in _vimrc but still no luck. >> :map shows ctrl-v is not mapped at all, I cannot comprehend how ctrl-v >> does not paste on a windows machine. Even worse, I did that somehow, but >> cannot remember how. >> > > Normally, Ctrl-V in Vim starts Block-Visual if in Normal mode, or Literal > insert in Insert or Command-line modes. However, if you source mswin.vim, it > maps it to "paste from clipboard", whose "normal" Vim command is "+gP > > See also > :menu Edit.Paste > in gvim, or after sourcing $VIMRUNTIME/menu.vim in a Console Vim with +menu > compiled-in. > > > It does paste in all other applications, so I must have done something >> within vim and not on Windows level. >> I did find the unix like ctrl-ins, shift-ins copy/paste definition, but >> not ctrl-v to visual mode mapping. >> > > Since you called the file .gvimrc on Unix, you won't have a .vimrc then, > and your Unix vim will run in 'compatible' mode, and, if in Console mode, > without sourcing the file at all. > > > This is in my _vimrc: >> ... >> " 2008.11.19: rev18, Peter Princz: Ctrl-Insert/Shift-Insert to >> copy/paste in visual/insert modes >> ... >> " Peter Princz (2008-Nov-19_125207) >> vnoremap <C-Insert> "+y >> inoremap <S-Insert> <Esc>"+gpi >> Please help. If needed, I can send the whole _vimrc file for >> troubleshooting. >> Have a nice day, >> Peter >> > > From the above, it doesn't seem to source mswin.vim at all. To use it (if > you still want to after all my warnings above), check that it contains one > (not both) of > > runtime mswin.vim > or > source $VIMRUNTIME/mswin.vim > > > Best regards, > Tony. > -- > To get something done, a committee should consist of no more than three > men, two of them absent. > -- You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php
