Investigating further, I think the problem may lie in lines 109--114
of remoteOpen.vim (quoted below)
" If none of the servers have the file open, then open this file in the
" first server. This has the advantage if yap tries to make vim open
" multiple vims, then at least they will all be opened by the same gvim
" server.
call remote_send(targetServer,
\ "\<C-\>\<C-n>".
\ ":let g:Remote_Server = 1\<CR>".
\ ":drop ".filename."\<CR>".
\ ":".linenum."\<CR>zv"
\ )
Could it be that the opening of a LaTeX file with this call differs to
the "classical" opnening is such a way that latex-suite mappings
overwrite the mapping
imap <buffer> <mapleader>i <Plug>Tex_InsertItemOnThisLine
(which I now fully understand) in my .vimrc ? Or, more precisely,
could it be that latex-suite as remotely loaded for the new file *does
not check* that such a mapping is already set ??
Thanks for any idea !
Julien
On Sun, Feb 15, 2009 at 12:05 PM, Julien Cornebise
<jul...@gm...> wrote:
> Dear all,
>
> As a french user, I have redefined the "e acute" mapping in my .vimrc
> with the line :
> imap <buffer> <mapleader>i <Plug>Tex_InsertItemOnThisLine
> This is perfect, I can type "é" without any problem, fine.
>
> However, when I'm doing backward search from my viewer, which calls
> the classical
> gvim -c ":RemoteOpen +%l %f"
> then the "é" maps back to "\item" -- whereas the rest of my .vimrc
> file is taken into account.
>
> Would you please know how I can prevent RemoteOpen.vim to overwrite
> the item insert ? To be fully honest, as have already been discussed
> on this list a few days ago, I do not entirely understand the
> "<mapleader>i <Plug>" part of the above command.
>
> Thanks for any help !
>
> Julien
>
|