Hi Gary,
Thanks for the tip. I actually dived in and opened up the session file and
compared it to an identically generated (same files and everything) session
file which didn't exhibit the problem. There were no occurrences of << in the
session file, however I did find these lines which for whatever reason were not
being displayed in :map
map ^V<C-«> :call ChangeFontSize("up")
map ^V<C-Â> :call ChangeFontSize("down")
map ^V<C-ª> :call ChangeFontSize("")
Now these are duplicates of the following:
map <C-S-kPlus> :call ChangeFontSize("up")<CR>
map <C-S-kMinus> :call ChangeFontSize("down")<CR>
map <C-S-kMultiply> :call ChangeFontSize("")<CR>
Removing the offending mappings fixed << which now works as expected. My only
worry is how these were generated in the first place, and if they will come
back. I shall keep the list informed if I can find anything else useful.
Thanks for everyone's suggestions and help!
Max
> -----Original Message-----
> From: Gary Johnson [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 20, 2006 3:22 PM
> To: vim@vim.org
> Subject: Re: Problems with <<
>
> On 2006-10-20, Max Dyckhoff <[EMAIL PROTECTED]> wrote:
> > 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.
>
> If you can do everything up through :mksession without observing the
> problem, then :so session and observe the problem, then you've
> narrowed it down to something funny happening during the :so session
> operation.
>
> As for the error in one of your HTML docs, that may be another
> manifestation of this problem. When you observe an error and you
> don't know what it's caused by, it is very difficult to say for sure
> what the error has and has not affected. Posting the error message
> here may give someone an idea of what could be happening.
>
> Another idea would be open the session file and look around, perhaps
> searching for ">>".
>
> Still another idea would be to look at
>
> :help bugreport
>
> and generate a bugreport.txt file as described there, then search
> that file for ">>". You could also create a bugreport.txt file at
> the last possible moment before the onset of this problem, then
> create another bugreport.txt file after the problem appears, then
> diff the two.
>
> Gary
>
> --
> Gary Johnson | Agilent Technologies
> [EMAIL PROTECTED] | Wireless Division
> | Spokane, Washington, USA
