On Wed, 21 Sep 2011, Spiros Bousbouras wrote:
On Sep 18, 11:14 pm, "Benjamin R. Haskell" wrote:
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
On Sep 18, 5:45 pm, "Benjamin R. Haskell" wrote:
On Sun, 18 Sep 2011, Spiros Bousbouras wrote:
The problem is that the filetype is being detected again every time
you switch buffers. Apparently Debian (like most distros) has a
bunch of auto-detection on filetypes. [...]
since your filetype isn't set up the way Debian expects it (which
may or may not be the way Vim normally does it), did_filetype()
returns 0.
Actually I have disabled running the Debian specific stuff in
/etc/vim/vimrc so the explanation even for what I describe in my
opening post must be the same as below. I tried again running what I
describe in the opening post with verbose set to 20 and the only
autocommand executed is the one I set up explicitly , there's no if
!did_filetype() .
Okay. I really don't understand why you're bent on disabling the
"normal" Vim filetype mechanisms. With them disabled, yes, you'll not
see anything related to them (including the BufRead autocmd). Maybe I'm
missing something.
I wasn't using -u NONE, sorry. I was explaining what goes wrong
without it. In the -u NONE case that you present, it gets cleared
because syntax starts fresh prior to loading each new buffer, so that
filetype detection can detect the file and load the proper syntax
without having to worry about clearing out the syntax of whatever
other file or files are open.
Right. This brings us back to what I was saying in the OP namely that
it is a strange design choice. Note in particular that buffer local
variables are remembered yet syntax is not. As I understand it ,
syntax is buffer specific. So why would syntax from other files have
to be cleared and why would proper syntax have to be reloaded ? I
can't think of a scenario where I'm editing a buffer , set up a syntax
, move away , return to the buffer and now a different syntax has to
be valid.
It's not that you're just moving from one buffer to another. It's that
you are unloading the file entirely (because you don't/didn't have
'hidden' set). When you load a file, its syntax starts fresh, and
needs to be set up. No way around that.
There are a few ways to avoid having Vim load the buffer from scratch
each time you switch to it. One way is to set the 'hidden' option.
Another is to set bufhidden=hide. Both of those alter how buffer
management works slightly. (You can switch away from a buffer that
contains unsaved changes, for example, though Vim will prompt you
about that if you try to exit.)
I have autowriteall set. Up to today I had &hidden == 0 and when I
moved away from a buffer the buffer was automatically saved. With
&hidden == 1 this no longer happens. Is there a way this can bite me
? I don't think there is but just to make sure. In particular , doing
ZZ or :q still seems to save all my buffers.
I've never used 'autowrite' or 'autowriteall', so I don't know what
you're used to. Moving through windows (not buffers) doesn't appear to
be one of the things in the list that triggers an automatic write.
ZZ will still save all your buffers.
:q / :qa will still write everything (with 'autowriteall').
Personally, I think 'autowriteall' sounds like a bad idea. Once you
start working with multiple buffers and windows, you'll probably get
used to the ability to have hidden buffers laying around. Without
'autowriteall', if you try to :qall, it will prompt you about the
hidden, unsaved buffers. With 'autowriteall', it seems like it'd be
easy to have a hidden, unsaved buffer whose changes you don't want to
have saved.
[...] the following works for me. [...]
1. Change your autocmd for detection [...] to:
ii. [...] just put it in ~/.vim/ftdetect/myfile.vim [...]
au BufReadPost,BufNewFile *.myfile setf myfile
2. And create a file ~/.vim/syntax/myfile.vim containing just the
following two lines:
syn match special /special/
hi special term=bold cterm=bold
Thanks but if these are the alternatives then it's simpler just to
reexecute the syntax commands every time the buffer is loaded.
Maybe I'm missing something, but my suggestion is simpler than (or at
worst "as simple as") what you're already doing. And it has the
benefit of being better-contained: All your Vim-related settings are
in your ~/.vimrc file and ~/.vim directory (and its subdirs).
I do actually have a ~/vim-scripts directory where I have all my , you
guessed it , vim scripts ! Not mentioning it was one of the
"simplifications" of my OP i.e. I was leaving out irrelevant details.
I chose the name vim-scripts a while ago when I didn't know that
~/.vim has special significance.
~/.vim is only special insomuch as it is added to 'runtimepath' by
default (along with its '/after' directory). Personally, I also have a
~/.vim.local directory so that I can share the same ~/.vimrc + ~/.vim/
hierarchy between all the machines I use, but keep machine-specific
settings/plugins/filetype-plugins/etc. in their own directory.
If you want to replace ~/.vim/ by ~/vim-scripts in all the examples
presented, you can add the following to your ~/.vimrc (or whatever you
call your ~/.vimrc):
" add non-default directories to 'runtimepath'
let &rtp='~/vim-scripts,'.&rtp.',~/vim-scripts/after'
= What you could be doing (one version): =
1. in your .vimrc (3 lines):
aug filetypedetect
au BufReadPost,BufNewFile *.myfile setf myfile
aug END
" The aug[roup] might not be necessary, but it makes management easier
2. put ~/myfile.vim into a different directory ( ~/.vim/syntax/ ) and
remove all but the last two lines (2 lines):
syntax match special /special/
highlight special term=bold cterm=bold
Your version seems to me more roundabout than mine. Instead of
directly sourcing the file you want sourced you set some option and
then vim on its own will source the file. So what does the
intermediate step of setting the filetype option buy you ? Nothing
that I can see.
It doesn't help much if you're unwilling to go the "normal" filetype
detection route. Maybe you have your reasons, but personally, I find it
much easier to let Vim handle filetype detection/syntax/etc. for the
filetypes it knows about. My solution only helps when you're not
fighting the standard mechanism.
Another thing I don't like about your version is the change of the
flow of execution which happens behind the scenes. This is something
I'm very wary of in any language. I don't like it when the natural
flow of execution (i.e. commands get executed or expressions evaluated
one after the other as they appear in the file) gets changed in a
manner which is not immediately obvious. :source somefile is explicit
but setting an option is not because setting most vim options does not
change the flow of execution.
All of the filetype-related "behind the scenes" stuff is well-documented under
:help filetypes
Other sources of info:
:help :setfiletype
:help 'filetype'
Finally , your version ties you up to a directory having a specific
name.
See above re: 'runtimepath'. The subdirectory has to have a specific
name, but the base can be changed.
The only thing your version has over mine is that you avoid the if
exists("b:myfile") guard but in my full script I need this anyway
for reasons apart from highlighting. And your version also has the
aug filetypedetect part. So all things considered I would say that
your version is more complicated than mine.
Again, it's only more complicated because you seem to want to disable
Vim's "normal" filetype detection. (Which, to me, seems pointless and
limiting.)
= What you could be doing (the other version): =
1. in ~/.vim/ftdetect/myfile.vim (1 line):
au BufReadPost,BufNewFile *.myfile setf myfile
2. put the last two lines of ~/myfile.vim into ~/.vim/syntax/myfile.vim
(2 lines):
syn match special /special/
hi special term=bold cterm=bold
All the comments above (apart from using aug filetypedetect) still
apply. And here you need 3 directories having specific names , ~/.vim
, ~/.vim/ftdetect and ~/.vim/syntax .
Yep. And again, mine do, too: ~/.vim/ isn't hardcoded, it's just set by
default.
Using Tony's suggestion of ~/.vim/filetype.vim reduces the number of
files per-filetype by one. I only prefer this method because it's easy
to include other people's custom filetypes. And, if one of my own
filetypes becomes useful enough, other people can use it in the "normal"
way.
--
Best,
Ben
--
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
