conflicting options: smartindent & 'fo+=a'

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'? :-)

--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php