Max Dyckhoff wrote:
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
Oh, so you meant « (opening French quote) and not << (less-than less-than) ! That was nowhere apparent in your previous postings. The next time you ask for help, please be as precise as you can be, and never assume that anyone will understand what you abbreviate or leave unsaid.
Now about how these mappings were generated in the first place: When you use key names like <C-S-kPlus>, the ":map" commands translates that to the actual keycodes used on your present computer and terminal (according to the present termcap), and stores the codes. When you use ":mksession", it copies the codes (with a prefixing Ctrl-V), not the key names, to the session file. So (IIUC) the session file must be sourced on the same OS and terminal as where ":mksession" was run. A session file is not a proper way to transfer complex mappings from gvim to console Vim (or vice-versa), from an xterm to /dev/tty (or vice-versa) nor between versions of Vim running on different OSes. And if you change the 'encoding' between making a session file and sourcing it (for instance by making the session file in UTF-8 and sourcing it in Latin1), that too could have catastrophic results, because each 'encoding' represents the same characters in a different way. Even if you're on Windows and not using Unicode, the OS starts gvim with one 'encoding' (such as Windows-1252) and console Vim with another one (such as cp850), leading to different meanings for many bytes above 0x7F.
Best regards, Tony.
