> 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:
>>
>>> 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 trying to disable the normal filetype detection mechanisms
> per se , I was trying to get rid of functionality I found irritating
> and which seemed to be the result of filetype detection. It's been
> around 4 years so I don't remember for sure but I think that one thing
> that annoyed me was that I was writing Scheme code , added a ; in the
> beginning of some line (which counts as a comment in Scheme) and then
> vim started adding a ; at the beginning of all subsequent lines. I
> think it also did parenthesis matching which I found distracting and
> possibly also syntax highlighting which yet again I found distracting.
> (When it comes to syntax highlighting in most situations I don't want
> any. What prompted this thread was the requirement for some very
> simple highlighting in a file type of my own for which there won't be
> any ready made plugins nor will it be useful to anyone apart from
> myself.) The fact that the Debian specific stuff also sets up some
> autoevent , as you said earlier in the thread , which probably
> wouldn't be useful to me either , confirms in my eyes the wisdom of my
> old decision to disable Debian specific stuff.
Tony points out solutions for some of the things you found annoying in
his response to this message. I also wanted to add a few things:
1. I'm pretty sure there's nothing "Debian-specific" here. That was
just my earlier assumption when what seemed like normal filetype
behavior wasn't occurring on your system.
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.
If you reeeeally don't want normal syntax highlighting, feel free to
keep doing what you're doing.
>>>> [...] In the -u NONE case that you present, it gets cleared
>>>> because syntax starts fresh prior to loading each new buffer [...]
>>
>>> 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.
>
> 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.
> 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.
> 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.
>>> 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.
>
> 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).
>>> 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'
>
> Yes , I read some of it before and after starting the thread but it's
> quite big and I don't have the time to read the whole of it in detail.
> In any case it doesn't affect the point I was making : I don't like
> behind the scenes change of the flow of execution , it's like an
> invisible goto. (And I don't even have a problem with visible goto's
> !) In this case it's like several invisible gotos since several files
> may be sourced. It's better of course if it's documented than if it's
> not but I'd rather avoid it altogether.
I'm not sure I buy that it's much like an invisible 'goto'. It's simply
a convention. Instead of having every filetype independently code up a
"load each file I need", it just uses well-known names, and if those
files exist, they're loaded.
> 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
> 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.
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)
--
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
No comments:
Post a Comment