> 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 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.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
183. You move your coffeemaker next to your computer.
--
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