Re: BufRead not reexecuted when returning to a buffer?

Thank you gentlemen for your thoughts.  I tried the BufEnter event (adding it to the list) and it didn't help.  Indeed, the existance of a BufEnter event raises the question of why BufNewFile or BufRead events ... what the difference is between BufEnter and BufRead is.

As to the question of why the coloring goes away when I leave a buffer, I thought that might point to the problem, but then I discovered that if I say,

  vim  known-file  unknown-file

on the command line, known-file colorizes according to its suffix, but unknown-file doen't   But

  vim unknown-file

does colorize properly (until I switch buffers)

ah, important information forgotten to be supplied - it is a known type, just the wrong one.  It's some file type called "conf".  So, the recognition algorithm keeps looking ...

2013/7/20 Tony Mechelynck <antoine.mechelynck@gmail.com>

On 07/19/13 23:42, Charles Smith wrote:

I have these commands in my ~/.vim/filetypes.vim file:

function DetectFind()
    let myfn = "/home/cts/nodes/vim/".expand ("%:t").".vim"
    execute "source ".myfn
endfunction


au BufNewFile,BufRead /home/cts/nodes/f0/test/find/* call DetectFind()


And it works fine when I start up vim - if there's a vim file with the same root as the file I'm editing, it'll colorize it.

The problem is, if I switch buffers and come back, it doesn't colorize - I suspect that DetectFind() isn't being invoked again.

I've looked at all kinds of things, did_filetype, my own did_* flags, clearing autocmds, verbose mode, etc. etc.

Any help will be appreciated

Commands in filetype.vim are meant as part of the filetype detection mechanism. They are invoked at BufNewFile (when creating a new file) and at BufRead aka BufReadPost (after opening a new editfile and displaying it in a buffer).

They should set the filetype of recognised files by either using the setf[iletype] command (set the filetype if it hasn't yet been set) or (locally) setting the 'filetype' option (set the filetype unconditionally).

Syntax coloring is done by syntax scripts, run once for each file at the Syntax event, and should not need to be done repeatedly for files already loaded. Similarly, setting options and declaring mappings for a given filetype should be done buffer-locally in a filetype-plugin, which is run once at the Filetype event, and uses commands like :setlocal and :map <buffer>. These also, don't need to be repeated every time you enter into the file.

You seem to be asking why the coloring isn't reapplied when you move back to an existing window, I'd rather ask why it goes away when you move out of it.


Best regards,
Tony.
--
        I think for the most part that the readership here uses the c-word in
a similar fashion.  I don't think anybody really believes in a new, revolution-
ary literature --- I think they use `cyberpunk' as a term of convenience to
discuss the common stylistic elements in a small subset of recent sf books.
                -- Jeff G. Bone

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/GFfp4YlD9Pw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
 
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.