> On 25/09/11 17:35, Spiros Bousbouras wrote:
>> On Sep 21, 7:38 pm, "Benjamin R. Haskell"<vim@benizi.com> 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.
>
> That's customizable. I think that
>
> :set fo-=c fo-=r fo-=o fo-=q
>
> will disable all comment formatting and all comment leaderinsertion;
> though youmay want something less drastic, see :help fo-table
>
>> I think it also did parenthesis matching which I found
>> distracting and possibly also syntax highlighting which yet again I
>> found distracting.
>
> That is also customizable.
>
> Method I: to disable it entirely: add the line
>
> let loaded_matchparen = 1
>
> in your vimrc.
>
> Method II: to disable it by default, but with possibility to re-enable:
> add the line
>
> au VimEnter * NoMatchParen
>
> to your vimrc. You can then use
>
> :DoMatchParen
>
> and
>
> :NoMatchParen
>
> to enable and disable parenthesis matching respectively, see :help
> matchparen
>
>> (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.
>
> Compiling your own Vim will by default put the executable in
> /usr/local/bin, equate (if unset) $VIM with /usr/local/share/vim,
> $VIMRUNTIME with /usr/share/vim/vim73, and look for the system vimrc at
> $VIM/vimrc. When compiled by a distro, I'm not 100% sure about Debian,
> but typical settings (as used by openSUSE) are /usr/bin, /usr/share/vim,
> /usr/share/vim/vim73 and /etc/vimrc. Both will look for your own vimrc
> at ~/.vimrc. So if you have both, your own Vim takes precedence (it is
> first in the $PATH) and the distro stuff isn't used.
>
>>
>>>>> 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.
>
> If you don't set hidden, and use ":filetype plugin on" and ":syntax on",
> the syntax highlights will be loaded once per buffer at buffer load. I'm
> not sure what happens with 'hidden'.
>
> If you use :syntax on followed by :filetype off, you won't by default
> get any highlighting since filetypes won't be detected. You can then set
> syntax for one file by means of
>
> :setlocal syntax=foobar
>
> and by using :setlocal you will avoid changing the syntax settings of
> other present or future buffers.
>
> If you want no highlighting in general but automatic syntax highlighting
> for sompe particular files, you can have
>
> syntax on
> filetype off
>
> (in that order) in your vimrc, then a syntax-setting modeline near the
> beginning or the end of the files which interest you. Here are a few
> examples of such modelines:
>
> // vim:ft=cpp:
>
> /* vim: set ft=c :*/
>
> <!-- vim: set ft=html :-->
>
> # vim:ft=sh:
>
> vim:tw=78:ts=8:ft=help:norl:
>
>
> The second form (with "set") is necessary when you need a comment
> trailer (as above for C and HTML, where the comment doesn't end at
> end-of-line). See :help modeline
>
>>>
>>> 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 also use 'autowriteall'. I prefer it by far to 'hidden' which some
people find so useful. When I want _not_ to save a modified file, either
I don't give it a name, or if it already has one, I make sure I :quit!
it with a bang before I close Vim. It may be because the first editor
which I used seriously, on Dos 2 or some such, could use split-windows
but would save the current file whenever (if modified) you changed windows.
>>
>>>> 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.
>
> If you don't have the time to get to know your tools, it's not my fault
> if you can't use them. You should take the time to read the help about
> anything in Vim that you don't yet know inside and out (and even
> occasionally about some things that you think you do know inside and
> out), in the long run it will make you more proficient, and the hour
> (maybe) that you "lose" today will be repaid over and over by "winning",
> maybe, ten minutes every day: in this example the "debt" will be repaid
> in a week. It's the old proverb: Give a man a fish, he'll eat for one
> day. Teach him how to fish, he'll eat his whole life long.
>
>> 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 ?
>>
>
> Easy.
> For all files currently loaded in Vim:
>
> :filetype on " unnecessary if already set
> :echomsg 'Files of type foobar currently loaded:'
> :bufdo if &ft == 'foobar' echomsg bufnr('%') . ':' expand('%:p') | endif
>
> For all files in a given directory:
>
> :filetype on " unnecessary if already set
> :cd /some/place
> :args *
> :echomsg 'Files of type foobar in /some/place'
> :argdo if &ft == 'foobar' echomsg expand('%:t') | endif
>
> See
> :help :bufdo
> :help :argdo
> :help expr-option
> :help :echomsg
> :help expand()
> :help filename-modifiers
> etc.
Oh, and if you meant all the Vim scripts which handle a given filetype
(let's say foobar) it's also rather easy: just list any file named
ftplugin/foobar.vim ftplugin/foobar_*.vim or ftplugin/foobar/*.vim below
any directory listed in 'runtimepath'. Since the default syntax is
usually the same as the filetype, you may want to add syntax/foobar.vim
and syntax/foobar/*.vim to these.
see :help 'runtimepath'
>
>
>
> Best regards,
> Tony.
--
The correct way to punctuate a sentence that starts: "Of course it is
none of my business, but --" is to place a period after the word "but."
Don't use excessive force in supplying such a moron with a period.
Cutting his throat is only a momentary pleasure and is bound to get you
talked about.
-- Lazarus Long, "Time Enough for Love"
--
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