Re: Can't put text with P, but p still works
On Fri, 14 Jul 2006, Yakov Lerner wrote: > On 7/14/06, Dr Bean <[EMAIL PROTECTED]> wrote: > >On Fri, 14 Jul 2006, Benji Fisher wrote: > >> On Fri, Jul 14, 2006 at 10:02:48AM +0800, Dr Bean wrote: > >> > map P reveals no mappings. > >> > This is the vim on Fedora Core 3. > >> > :version > >> > VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 19 2004 17:17:57) > >> > 適用済パッチ: 1-21, 23-24, 26, 28-30 > >> > Modified by <[EMAIL PROTECTED]> > >> > Compiled by <[EMAIL PROTECTED]> > >> > Huge 版 without GUI. 機能の一覧 有効(+)/無効(-) > >> Please try starting vim with > >> $ vim -u NONE > >> and see whether the problem persists. If it does, please give a very > >> explicit example of how "p" works but "P" does not. > >It appears to be a sessions problem. I only have it when I run > >vim -S Sessions.vim. > >With vim -u NONE -U NONE the problem with P in a session goes away. BUt I > >get > >vi-undo with u. > >This suggests session monkeying with cpoptions is to blame. > >And I have in my vimrc: This is actually the system vimrc. I don't have a ~/.vimrc. > >map \P :set paste!: se paste? > >And although P doesn't do anything except in ex: mode, I see it is > >toggling > >the paste option. > >I wonder if this is cpo flag B. > It does. I don't know it whis is intended behaviour or not, > but your problem goes away if you do >set cpo+=B > Can you verify that your &cpo has no 'B' ? Mine 'cpo' does. I have cpoptions=aABeFsM In a session, cpoptions=aABeFs, the vim default apparently. B is present both times, so it looks like the explantaion is more complicated. With -u NONE -U NONE, cpoptions=aAbBcCdDeEfFgijJkKlLmMnoOprRsStuvwWxy$!%*< > The small experiment shows this: > 1. :set cpo+=B >:nmap \P :echo "abc" >\P shows abc on commandline >P does not Yes, I get the same outside a session. > 2. :set cpo+=B I think you mean :set cpo-=B > :nmap \P :echo "abc" >P shows abc on commandline !!! >\P shows abc on commandline Yes, I get the same outside a session. > I don't know whether this is intended or bug. > >From the text that descibes 'B' flag of 'cpo', it > does not follow that without B backslash shall > ignored in rhs of mapping. Yes, it's a bit difficult to reconcile the two. A number of plugins change cpo. I seem to have broken Luc Hermitte's bracketing macros with my own changes. On another machine I am getting: Error detected while processing function 15_LoadBrackets..Trigger_Function..Trigger_DoSwitch..Brackets: line 70: E10: \ should be followed by /, ? or & The help says this is often caused by command-line continutation being disabled by the C flag. Perhaps all these cpo anomalies are a symptom of my careless hacking. -- Dr Bean All teaching is teaching under difficult circumstances. --Dr Bean
Re: Can't put text with P, but p still works
On 7/14/06, Dr Bean <[EMAIL PROTECTED]> wrote: On Fri, 14 Jul 2006, Benji Fisher wrote: > On Fri, Jul 14, 2006 at 10:02:48AM +0800, Dr Bean wrote: > > map P reveals no mappings. > > This is the vim on Fedora Core 3. > > :version > > VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 19 2004 17:17:57) > > 適用済パッチ: 1-21, 23-24, 26, 28-30 > > Modified by <[EMAIL PROTECTED]> > > Compiled by <[EMAIL PROTECTED]> > > Huge 版 without GUI. 機能の一覧 有効(+)/無効(-) > Please try starting vim with > $ vim -u NONE > and see whether the problem persists. If it does, please give a very > explicit example of how "p" works but "P" does not. It appears to be a sessions problem. I only have it when I run vim -S Sessions.vim. With vim -u NONE -U NONE the problem with P in a session goes away. BUt I get vi-undo with u. This suggests session monkeying with cpoptions is to blame. And I have in my vimrc: map \P :set paste!: se paste? And although P doesn't do anything except in ex: mode, I see it is toggling the paste option. I wonder if this is cpo flag B. It does. I don't know it whis is intended behaviour or not, but your problem goes away if you do set cpo+=B Can you verify that your &cpo has no 'B' ? Mine 'cpo' does. The small experiment shows this: 1. :set cpo+=B :nmap \P :echo "abc" \P shows abc on commandline P does not 2. :set cpo+=B :nmap \P :echo "abc" P shows abc on commandline !!! \P shows abc on commandline I don't know whether this is intended or bug. From the text that descibes 'B' flag of 'cpo', it does not follow that without B backslash shall ignored in rhs of mapping. Yakov
Re: Can't put text with P, but p still works
On Fri, 14 Jul 2006, Benji Fisher wrote: > On Fri, Jul 14, 2006 at 10:02:48AM +0800, Dr Bean wrote: > > map P reveals no mappings. > > This is the vim on Fedora Core 3. > > :version > > VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 19 2004 17:17:57) > > 適用済パッチ: 1-21, 23-24, 26, 28-30 > > Modified by <[EMAIL PROTECTED]> > > Compiled by <[EMAIL PROTECTED]> > > Huge 版 without GUI. 機能の一覧 有効(+)/無効(-) > Please try starting vim with > $ vim -u NONE > and see whether the problem persists. If it does, please give a very > explicit example of how "p" works but "P" does not. It appears to be a sessions problem. I only have it when I run vim -S Sessions.vim. With vim -u NONE -U NONE the problem with P in a session goes away. BUt I get vi-undo with u. This suggests session monkeying with cpoptions is to blame. And I have in my vimrc: map \P :set paste!: se paste? And although P doesn't do anything except in ex: mode, I see it is toggling the paste option. I wonder if this is cpo flag B. -- Dr Bean Doing things right is doing the right thing. Doing things wrong is education. --Dr Bean
Re: Can't put text with P, but p still works
On Fri, Jul 14, 2006 at 10:02:48AM +0800, Dr Bean wrote: > map P reveals no mappings. > > This is the vim on Fedora Core 3. > > :version > VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 19 2004 17:17:57) > 適用済パッチ: 1-21, 23-24, 26, 28-30 > Modified by <[EMAIL PROTECTED]> > Compiled by <[EMAIL PROTECTED]> > Huge 版 without GUI. 機能の一覧 有効(+)/無効(-) Please try starting vim with $ vim -u NONE and see whether the problem persists. If it does, please give a very explicit example of how "p" works but "P" does not. Since your version of vim was modified and compiled by redhat, I am tempted to blame them for any problems, but it is too early to make that decision now. HTH --Benji Fisher
