Alan G Isaac wrote:
On Mon, 4 Dec 2006, Bill McCarthy apparently wrote:
Instead of using an autocmd, you could place those maps in a file called tex.vim in your local ftplugin directory. Place this single line in such a file: map <buffer> <c-a> :echo 'It worked!'<CR>

OK, I did this.
But there is still a problem.

Suppose I have defined::

    imap <buffer> <unique> ;fn %<cr>\footnote{%<cr>}<cr>%<esc>-i

in my tex_ai.vim file in my local ftplugin directory.
I create the buffer ``:e c:\temp.tex``
then I leave the buffer by deleting it ``:bd``
and then later I decide to reopen it ``:e c:\temp.tex``.
Now I get a bunch of E227 errors, saying the mapping already exists. This must mean that there Vim tries to redefine the mapping.

BUT I had tried to rule this out: at the top of my plugin I have::

    if exists("b:loaded_tex_ai")
            finish
    endif
    let b:loaded_tex_ai=1

But of course ``b:loaded_tex_ai`` is gone once I use ``:bd``.

It is not gone, it is just marked as "unlisted". ":ls!" (with exclamation mark) will show you that the so-called "deleted" buffer is still around.

But the mappings are apparently still around!
I do not really understand the variable convetions.
Should I have created ``s:loaded_tex_ai`` instead?
Might that work?

Global plugins normally use a global variable. This has the following 
advantages:

- If you have more than one version of a single plugin, only one version will 
run.
- You can disable the plugin by setting the variable.

Filetype-plugins should run once per applicable buffer, at the filetype event, or at some event dependent on the Filetype event (like Syntax). They should not set anything that would "carry over" to different buffers. In particular, mappings should have the <buffer> modifier and options should be set using ":setlocal". These should use a buffer-variable, like you did.


The problem does not arise if I use ``:bw`` instead of ``:bd``.
But then I lose other information too.

Only ":bwipeout" really deletes everything Vim knows about the buffer.


What is the right way to manage this?
Hints or suggestions?

Thank you,
Alan Isaac

What you can do is to merely "unload" the buffer (write it to disk and edit something else in its stead). Then if and when you later decide to edit the first buffer again, there shouldn't be any errors.


Best regards,
Tony.

Reply via email to