wrote:
> 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:
>
> > 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 never doubted it would be customizable. But disabling
filetype detection altogether is even simpler.
> > 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
Thanks but whenever I'm in doubt that my parentheses , braces or
whatever match I do % .But having it on all the time is just
distracting. My general mentality when using applications is "don't
show me something unless I asked for it" unless I'm about to make a
really big screw up. So you can see that before I disabled filetype
detection and vim was showing me all that stuff I hadn't asked for it
was driving me up the wall.
> 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.
In my case there is a /usr/share/vim/vimrc which is a symbolic link
to /etc/vim/vimrc .I do have a ~/.vimrc but /etc/vim/vimrc still
gets executed. /etc/vim/vimrc has a line
runtime! debian.vim
which I have commented out.
> >>>> 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'.
I tried these precise settings (with 'hidden' off) and repeated the
test of my opening post. Leaving the buffer and returning still turns
off syntax highlighting.
> 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:
No , no , no , having option modeline on is dangerous.
> // vim:ft=cpp:
>
> /* vim: set ft=c :*/
>
> <!-- vim: set ft=html :-->
>
> # vim:ft=sh:
>
> vim:tw=78:ts=8:ft=help:norl:
[...]
> >> 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.
What do you mean it's not your fault , of course it is your
fault :-D
> 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,
Not necessarily. Not all vim functionality is useful to all people.
Some of it may increase my productivity but some won't. It's possible
that reading in detail all the filetype related documentation would
increase my productivity but based on what I have read and what
people here say , it seems unlikely. If I had time to read everything
I want then I would read it but since I don't , I have to go by the
odds and the odds in this case are that it won't help me.
> 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.
A week ? Not likely since it would take me a lot more than a week to
learn inside out all vim functionality.
> 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.
>
> > 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 ?
Silly me , I forgot that vim also has ls and find commands. I meant
get a listing from the shell command line and the Unix ls and find
commands.
> 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
^
Needs a | here
> 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.
--
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