> I am trying to insert a bunch of ugly text in 'css', and using
> syntax='css', si, (tried w/ai& /noai), and using formatoptions
> tag 'a'.
>
> I'm running into a minor conflict versus what I expect.
>
> Any time a line starts with a '.', everything gets indented
> a further level (even though there's no nesting).
>
> As near as I can tell, what's happening is this:
>
> input:
> ---
> .sel {
> blah;
> blah2;
> }
>
> .sel2 {
> bbb;
> ccc;
> }
>
> next {
> xxx;
> }
> ---
> becomes:
> .sel { blah;
> blah2; }
>
> .sel2 { bbb;
> ccc; }
>
> next { xxx; }
> -----------
>
> The closing brace's for '.sel' and '.sel2' are not being matched
> by the 'autoindent' algorith. Reason: 'ai' looks for closing
> brace in column 1 -- which it IS, in the input. However the 'fo+=a'
> option apparently gets a hold of the closing brace before 'ai'
> sees it and it puts it on the previous line (thus no longer in
> column 1). So 'ai' never sees the closing quote.
>
> What eventually caused (causes) the indent to be reset is
> a css "ID" selector definition. CSS id selector definitions
> start with '#'. Vim, of course, believes it to be a
> comment, and sets the indent from what is then about '60' back
> to 0.
>
> Um...
> Observations.
>
> Apparently the setting of 'syntax=' doesn't really effect a mode
> switch as far as actual input, but only affects coloring?
>
> Sigh.
>
> How unreasonable would it be for me to want 'syntax' settings to
> also apply to how 'si' and inserting "#" and indent keywords and
> ...well, whatever other auto-formatting features are in vim.
>
> Is that something that would need to be done on a syntax-by-syntax
> file basis?
>
> ==OR== is expecting (or wanting) that to be done in syntax
> files overloading 'syntax' files -- as they are only designed for
> visual syntax hilighting and not modifying vim's input parameters to
> be congruent with the visual syntax?
> I.e. is a 'input-syntax' file type needed? (I'd sorta hope not,
> but I ask) The only reason I ask is based on whether or not it
> is common or expected that current syntax files should
> adjust vim's other options (I'm guessing not (?)). If it's
> not common nor expected, then there's a "whole" people aren't
> expecting a 2nd input file to be written or provided to change
> input options, BUT, neither is it being provided in the current
> syntax file collection (maybe there are exceptions?)
>
> I don't suppose there are any easy ways around problems like this?
> I.e. I can set manual options here and there by figure out what the
> settings are for my particular circumstance, but that doesn't solve
> the general problem (nor do I think I'm sufficiently versed in
> the various options to solve such a general problem).
>
> Ideas? Comments? Is this a 'feature deficiency'? :-)
> Is it something that is fixable (from a design point of view,
> apart from the work needed add the changes for the various
> supported syntaxes). Should it be become some future standard
> for syntax files to (optionally) set all the input options
> associated with a particular syntax?
>
> Am I missing some setting that would just 'do the right thing'? :-)
>
The 'syntax' option, and the syntax plugins, only affect highlighting
(colouring, but also bolding, underlining, etc.), or rather, where
highlighted text starts and ends. (A colorscheme may define the actual
colors, unless you use the "default colours" compiled into Vim). That's
intentional.
The 'filetype' option affects the rest: indenting via an indent plugin
and a number of options like 'lisp', 'cindent', 'autoindent',
'smartindent', 'indentexpr', and I'm not sure I din't omit one or two;
the rest via a filetype-plugin.
If your vimrc includes both "filetype plugin indent on" and "syntax on"
(or if it sources the vimrc_example.vim, which issues both of these
commands) you get all three types of plugins loaded whenever you edit a
new file. Otherwise, depending on what you use in your vimrc, maybe you
get only part of them.
The syntax file for CSS should know that comments (blue text by default)
may start with /* or maybe with // but never with #, and IIUC, the
filetype-plugin should set the 'comments' option accordingly and the
indent-plugin set up indenting so that, for instance, CSS opening and
closing braces get balanced indent and outdent.
If you have used the above-mentioned commands in your vimrc, then
starting to edit a file recognized as CSS (probably because is name ends
in .css) will cause Vim to apply all three types of plugins to it
without further action; but if you start editing an empty [NoName] file,
Vim cannot read your mind to know that you mean it to be a CSS style
sheet, and setting 'syntax' to CSS isn't enough. The recommended way of
doing things is to give your file a CSS name right at the start; or
else, if you never intend to save the file, setting 'filetype' to css
(which will also set 'syntax') (or setting it to html etc. for an
embedded style sheet) will cause your style rules to be recognized as
what they are.
Best regards,
Tony.
--
Did you know that clones never use mirrors?
-- Ambrose Bierce, "The Devil's Dictionary"
--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
No comments:
Post a Comment