Hi Gary, and Yakov,

I'm sorry, I'm feeling terrible today so my bug reports aren't very 
comprehensive. More information!

WinXP, GVIM 7.0 compiled by Bram.

I don't have many plugins, the major ones being Lookupfile and associated 
plugins and vimoutliner. I seriously suspect vimoutliner is the culprit.

But that is actually only half of the story. The bad << mapping doesn't exist 
in a clean vim, even with all my plugins running, it only exists in the current 
session of vim that I am using. I run vim with 7 tabs open, each containing at 
least two files. I have three tabs full of .cpp files that I am working on, a 
tab with some AI scripting files, a tab with some HTML docs that I am writing, 
a tab with some init files, a tab with my .vimrc and a tab with my todo.otl 
file for vimoutliner.

When I reboot I do a :mksession ~/work_session.vim, and when I come back I :so 
~/work_session.vim so I can continue where I left off. This saves me loads of 
time reopening the 20 or so C files that I am working on at any one time, as 
well as all the various supporting files listed above.

This session has been around for a few weeks, and I keep :mksession-ing and 
:so-ing it. When I :so it I get an error in one of my HTML docs, but it doesn't 
seem to fail so I'm not worrying.

Do you think the session is somehow corrupted? It happens if I make the session 
again cleanly (open all the files in a new vim session, :mksession, :so 
session, observe strange behaviour), so just trashing the session and starting 
again isn't really an option, as the problem will come back within a couple of 
days.

Max



> -----Original Message-----
> From: Gary Johnson [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 20, 2006 2:01 PM
> To: vim@vim.org
> Subject: Re: Problems with <<
>
> On 2006-10-20, Max Dyckhoff <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > :verbose map << shows nothing. I have no mappings with << at the
> > start (or in fact, anywhere in the mapping).
> >
> > Removing the two ,, mappings did nothing useful. The only
> > "interesting" map that I have is one right at the end of the list
> > which is some non-printing character duplicating another mapping I
> > have for <C-S-+>. I have no idea how to identify this character.
> >
> > I agree that plugins shouldn't set the localleader, but in
> > fairness I don't ever use the local leader for anything other than
> > the vimoutliner plugin so I'm not too worried.
> >
> > Any more ideas as to what I could try?
>
> You could try determining which plugin is causing the problem.
>
>     1.  Choose a file that you've been editing when you've seen the
>         problem and start vim as you normally would, e.g., "vim
>         somefile", and verify that you see the problem.
>
>     2.  Using the same file, start vim as "vim -N -u NONE somefile"
>         and verify that you don't see the problem.
>
>     3.  Start vim as "vim --noplugin somefile" and see if you see
>         the problem.  (You may have to comment-out any "filetype"
>         lines in your .vimrc as well.)  If you do see the problem,
>         the cause is in your .vimrc; otherwise, the problem is in a
>         plugin.
>
> The best strategy for tracking down the problematic plugin depends
> on how many private plugins you have and of which kinds.  I would
> start by turning off all filetype detection in your .vimrc so that
> only ordinary plugins are loaded, then try "vim somefile" and see
> what happens.  If you still see the problem, then I would rename
> half the files in your ~/.vim/plugin directory with a dummy
> extension (.hide?) and repeat the experiment, doing a binary search
> on the file sets until you narrow it down to the problematic plugin.
>
> You can use the :scriptnames command during this process to see
> which plugins are actually being sourced.
>
> HTH,
> Gary
>
> --
> Gary Johnson                 | Agilent Technologies
> [EMAIL PROTECTED]     | Wireless Division
>                              | Spokane, Washington, USA

Reply via email to