> 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.
> >> 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.
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 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.
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. 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.
> > 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'
That's good to know. And doing :help rtp showed me in one place a
nice list of all the directories vim automatically searches which
helped clarify how things work.
> > 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 ?
> > 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 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. This is different than the way code is
organised in every other programming language I know of. 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 ?
--
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