BufRead not reexecuted when returning to a buffer?

[Charles Smith]

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

[tooth pik]

looks like you need BufEnter...

--
_|_ _ __|_|_ ._ o|
|_(_)(_)|_| ||_)||<
|

[Tony Mechelynck]

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

[Charles Smith]

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.m...@gmail.com>

--
--
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.

[Marcin Szamotulski]

On 16:49 Sat 20 Jul , Charles Smith wrote:
> 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 ...

Just try them:

autocmd BufEnter * :echom 'BufEnter '.expand('<afile>:p')
autocmd BufRead * :echom 'BufRead '.expand('<afile>:p')
autocmd BufNewFile * :echom 'BufNewFile'

Open files, open new files change the buffers: you will see taht BufRead
only fires when vim is reading a file from the disc (this is usually
done once, where vim starts or when you use :edit command) and BufEnter is
fired whenever you change the buffer, i.e. when you enter a buffer: for
example whenever you use the :b command or ^W normal commands to switch
between windows with different buffers.

Hope it helps,
Marcin

ps. please do not top-post the list prefers bottom-posting.

[Tony Mechelynck]

On 07/20/13 16:49, Charles Smith wrote:
> 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.

Let's say you do the following (I've tried to display autocommand event
sequences correctly but maybe I've inverted some):

vim
--> sources your vimrc; I assume it sets :filettype plugin on and
:syntax on
--> sources global plugins
--> VimEnter event
:e file1.c
--> BufReadPre event
--> reads the file into a buffer and displays it in the current window
--> BufRead[Post] event
--> filetype.vim recognises it as type "c"
--> FileType event
--> sources c.vim filetype plugins
--> Syntax event
--> sources c.vim syntax plugins
--> BufWinEnter event (or maybe earlier?)
--> BufEnter event
:new file2.c
--> BufLeave event (for file1.c)
--> then the same as above but for file2.c, except the file is
displayed in a _new_ (split) window.
Ctrl-W W
--> BufLeave event (for file2.c) \ and nothing else, because both files
are already each loaded in a buffer and displayed in a window
--> BufEnter event (for file1.c) /
:qa " assuming the files haven't been modified
--> BufWinLeave event (once for each file)
--> BufLeave event (once for each file)
--> VimLeave event
--> quits

See in the help the description of each event, e.g. :help BufEnter

So you see, BufReadPre and BufReadPost are invoked when reading the file
from disk, BufEnter and/or BufLeave are invoked each time you make a
different file current.


Best regards,
Tony.
--
Eye have a spelling checker, it came with my PC;
It plainly marks four my revue mistakes I cannot sea.
I've run this poem threw it, I'm sure your please to no,
It's letter perfect in it's weigh, my checker tolled me sew!

[Nikolay Pavlov]

You forgot about 'hidden' option. By default it is not set and vim reads buffer from disk each time it disappears from all windows and then is viewed again. Thus if one does not use windows and have default setting for 'hidden' there are less differences. BufRead is not fired for new files though.

> Hope it helps,
> Marcin
>
> ps. please do not top-post the list prefers bottom-posting.
>

> --
> --
> 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+u...@googlegroups.com.

[Marcin Szamotulski]

Good point, indeed I use hidden.

Regards,
Marcin