> On Sun, 25 Sep 2011, Spiros Bousbouras wrote:
> > On Sep 21, 7:38 pm, "Benjamin R. Haskell" wrote:
> >> On Wed, 21 Sep 2011, Spiros Bousbouras wrote:
> >>> On Sep 18, 11:14 pm, "Benjamin R. Haskell" wrote:
>
> 2. If you disable filetype- and syntax-highlighting behaviors, you
> shouldn't also be surprised when trying to do filetype- and
> syntax-highlighting things turns out to not work as expected.
The only thing I found surprising was that I was moving away from the
buffer , returning to it and the syntax wasn't remembered whereas
buffer specific variables were. Even if filetype detection was on and
I had put myfile.vim of my opening post under the appropriate
directory , the syntax highlighting commands would still get
reexecuted when returning to the buffer and that I find surprising.
I hadn't thought of the distinction between unloading the buffer and
simply moving away from the buffer. After all , if you really want to
unload a buffer you do :bunload
> >>> 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.
There is one : you are editing a buffer *and* the syntax highlighting
file for the buffer. So you start with the buffer , then move to the
highlighting file , make some changes and then return to the buffer.
Obviously you want the new syntax to take effect.
> >> 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.
> >
> > Yes , I understand how it works , I was just saying that I find it
> > strange. I thought you agreed with me earlier that it is strange.
>
> I found it strange that *moving* from one buffer and back changed your
> settings. I didn't realize when I agreed that it was strange that (1)
> you weren't just moving between windows (buffers != windows, but I made
> that bad assumption), and (2) that you didn't use 'hidden' (so it's not
> just moving between buffers -- you're loading a file every time you
> switch to a buffer).
>
> I find nothing strange about the way loading syntax-highlighting
> actually works, at least in the 'hidden' case. I do find it strange
> that buffer-specific variables are kept in that case.
You mean when 'hidden' is off , yes ? If buffer specific variables
weren't kept it would at least be consistent and the example of my
opening post would work as I expected even with filetype detection
off.
> > What prompted me to set autowriteall was exactly because I often tend
> > to move between different files and I found it irritating having to
> > add a ! to the commands for moving. Anyway I am more worried about
> > whether there is some sequence of key presses which will take me out
> > of vim without saving changes.
>
> Not without '!', as far as I'm aware.
Ok , then it's safe.
> > If I'm not sure that I want to keep the
> > changes I'm making to some file I just create a copy of it before
> > modifying it.
>
> That sounds like something that will just create a large amount of work
> removing one-off files later.
If it happened often yes but it's a very rare occurrence. Until this
thread I even had 'hidden' off which meant that when I moved away
from a buffer not only it saved it but I couldn't even undo changes
when I returned (with vim 7.1) .On one occasion in the last several
years it caused me to lose a minor piece of information when I
deleted the line which had it and then moved away from the buffer but
otherwise this set up has worked fine. But having 'hidden' on seems
to be better.
> > What does using option filetype buy you when you do use the normal
> > filetype detection mechanism ? One advantage I can see is that it
> > makes it easier to use plugins by other people. But if you're using a
> > file type of your own does using the filetype option offer you
> > anything ?
>
> Only consistency. Putting commands in one file
> (~/vim-scripts/myfile.vim) or another (~/vim-scripts/syntax/myfile.vim)
> shouldn't be *that* much of a hassle. And if you do it the way other
> filetypes do it (use the standard filenames), it happens the same way
> (they get loaded when they're needed).
>
> But, if you *really* don't use other filetypes, and disable the filetype
> detection mechanism anyway, there's no point to that consistency, since
> it's unused. So, the answer is "nothing". There's nothing better about
> doing it the right way when you disable all but your custom filetype(s).
Ok.
> > I also don't like how the functionality for one type of file is split
> > among several directories which will in general also contain
> > functionality for other kinds of files. So instead of having for
> > example one directory with all the plugins for say C source code , you
> > have a syntax directory where you have syntax stuff for C code , Lisp
> > code , etc. and then another directory for indentation stuff for C
> > code , Lisp code etc. and so forth for all other kinds of
> > functionality vim supports.
>
> It's organized by Vim function (ftdetect, ftplugin, syntax, indent)
> rather than by language. That split probably makes the most sense for
> filetype-detection, since a lot of it is used to determine what filetype
> you're in, so differentiating one dialect from another, or two filetypes
> that share common extensions [pl = Prolog / Perl] touches more than one
> "language".
>
> That the other three (syntax / indent / ftplugin) are also split in the
> same way probably has to do with being able to independently
> enable/disable the functionality. (You can turn filetype plugins on
> without filetype syntax with or without filetype indenting.)
>
>
> > This is different than the way code is organised in every other
> > programming language I know of.
>
> Virtually every programming language has conventions for where to load
> its library files. VimL (the language Vim uses) is no different.
>
> Though, you may be right that it would make more sense to see:
>
> c/ftplugin.vim
> c/syntax.vim
> c/indent.vim
> java/ftplugin.vim
> java/syntax.vim
> java/indent.vim
> lisp/ftplugin.vim
> lisp/syntax.vim
> lisp/indent.vim
Yes , that's the kind of thing I had in mind.
> > Say I want to have a listing of all the files associated with some
> > filetype. With the way things get done outside of vim you would use a
> > single ls command or a single find command. But with the way vim
> > organises things how do you do it ?
>
> One way would be to load a file of that type and run :scriptnames. But
> even that's not enough, because there's also an autoload mechanism. And
> as you yourself were doing previously, you can simply put a :source
> command into an autocmd. So, there's no nice, consistent way to get a
> full list. But why do you need that list anyway? If you're not using
> the normal mechanisms, that list won't matter.
I don't absolutely need it but it would be nice to have. Say I'm
curious to see what the total size of all lisp plugins is. Then if
things were organised the way I'm suggesting I could do (from the
shell command line)
wc lisp/*
The way things are organised I have to use something a bit more
complicated.
Or say I want to copy all the lisp plugins or send them over an email
or something. Then I could do
tar cf ~/vim-lisp.tar lisp
As things are I have to either learn a new tool , vimball , or again
use a more complicated tar command. In either case what I have to do
is not a lot more complicated but still it's a minor annoyance. I
also wonder whether the way I'm suggesting would work better with
version control software.
> If you do come around and decide to use the normal mechanism, the
> following seems like a good first pass:
>
> fun! FindFilesForType(ft)
> return split(globpath(&rtp,'{ftdetect,syntax,indent,ftplugin}/{,after/}'.a:ft.'{,{/,_}*}.vim'), "\n")
> endfun
>
> It will miss autoload files. (often used for 'omnicomplete' and by
> ftplugins)
--
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
No comments:
Post a Comment